Refactor waitFor* actions with resolveSelect.
#9978
Conversation
…etPropertySummaries()`.
…atchingWebDataStreamByPropertyID()` and `doesWebDataStreamExist()`.
…taStreamExist()` resolvers.
techanvil
force-pushed
the
enhancement/9008-remove-waitfor-actions
branch
from
dfc9788 to
7cea708
Compare
|
Build files for df6be4e are ready:
|
|
Size Change: -1.09 kB (-0.06%) Total Size: 1.98 MB
ℹ️ View Unchanged
|
|
LGTM 💯 Moving this to MR. |
There was a problem hiding this comment.
Thanks @techanvil – this looks solid overall. Looks like I missed the detail about AMP containers in the IB but it should be quick to address. A few other questions/suggestions below as well.
| fetchMock.getOnce( | ||
| new RegExp( | ||
| '^/google-site-kit/v1/modules/analytics-4/data/account-summaries' |
There was a problem hiding this comment.
Is this intentionally defined after render? I don't think we could be sure it would work this way.
There was a problem hiding this comment.
It is, yup. It was a bit of an odd one that took some digging to figure out what was going on.
I've added a clarifying comment, basically it's a side effect of adding the resolver for getPropertySummaries() which resolves getAccountSummaries().
There was a problem hiding this comment.
Thanks @techanvil – is it important that the resolver finishes? It seems to me that it would be more appropriate to update the fetch mock for the same endpoint above to freeze fetch "manually" using fetchMock.get rather than once so that it would handle both requests. I think the context of the comment is useful, but even if we keep the same mock, we should define it before render. This should be possible since it supports defining multiple matchers/mocks as well as simple repetition. See https://www.wheresrhys.co.uk/fetch-mock/docs/legacy-api/Usage/cheatsheet#timing-and-repetition
There was a problem hiding this comment.
Thanks @techanvil ! This is almost there, just a few comments left to address.
| fetchMock.getOnce( | ||
| new RegExp( | ||
| '^/google-site-kit/v1/modules/analytics-4/data/account-summaries' |
There was a problem hiding this comment.
Thanks @techanvil – is it important that the resolver finishes? It seems to me that it would be more appropriate to update the fetch mock for the same endpoint above to freeze fetch "manually" using fetchMock.get rather than once so that it would handle both requests. I think the context of the comment is useful, but even if we keep the same mock, we should define it before render. This should be possible since it supports defining multiple matchers/mocks as well as simple repetition. See https://www.wheresrhys.co.uk/fetch-mock/docs/legacy-api/Usage/cheatsheet#timing-and-repetition
| const summaries = | ||
| select( MODULES_ANALYTICS_4 ).getAccountSummaries( accountID ); | ||
|
|
||
| if ( summaries === undefined ) { | ||
| yield commonActions.await( | ||
| resolveSelect( MODULES_ANALYTICS_4 ).getAccountSummaries( | ||
| accountID | ||
| ) | ||
| ); |
There was a problem hiding this comment.
I think we can and should simplify this to be unconditional since there's no downside to calling the selector here. This kind of guard is only really necessary around fetch actions, but the WP data resolver infra will only run once regardless of when this is called so it should be perfectly safe to do.
Also, there could be a situation where the underlying resolver is invalidated where, using the current logic here would prevent it from running when it should.
| if ( ! isValidPropertyID( propertyID ) ) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
How about we move this guard to getWebDataStreams below? Then this function can resolve-select that here unconditionally similar to my comment above.
| const { select, resolveSelect } = yield commonActions.getRegistry(); | ||
|
|
||
| const containers = select( MODULES_TAGMANAGER ).getContainers( accountID ); | ||
|
|
||
| if ( containers === undefined ) { | ||
| yield commonActions.await( | ||
| resolveSelect( MODULES_TAGMANAGER ).getContainers( accountID ) | ||
| ); | ||
| } |
There was a problem hiding this comment.
Same as above – let's resolve select this unconditionally
Summary
Addresses issue:
waitFor*actions withresolveSelect#9008Relevant technical choices
PR Author Checklist
Do not alter or remove anything below. The following sections will be managed by moderators only.
Code Reviewer Checklist
Merge Reviewer Checklist