Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor
waitFor*
actions withresolveSelect
. #9978Refactor
waitFor*
actions withresolveSelect
. #9978Changes from 13 commits
05c9fce
52e24bb
2f1270a
dc7719c
31cda3e
db72f9b
06f851e
1a83f18
e770a7e
4740af6
367c00c
62fe359
7cea708
55d2eb9
32de116
f01ef5d
df6be4e
e32c7ce
c049c5d
525d660
7b78c6f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 resolvesgetAccountSummaries()
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 thanonce
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-repetitionThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not essential that the resolver finishes, and I'm happy to freeze both requests. I had initially done so, in fact, but decided to take this approach instead as I figured it spells out more clearly the precise flow of events.
However, happy to make the change and I have done so.
Although using
fetchMock.get()
to "manually" freeze the request works, I've taken the approach of modifyingfreezeFetch()
to allow a specific number of requests to be frozen. This retains the semantic value of callingfreezeFetch()
while making the test setup more explicit.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @aaemnnosttv, it does make sense to unconditionally call the resolver, and I've applied that change.
However, unless I've missed something, there are scenarios where a resolver can be called twice, as mentioned in my comment on the
PropertyOrWebDataStreamNotAvailableError
test in this PR.site-kit-wp/assets/js/modules/analytics-4/components/settings/PropertyOrWebDataStreamNotAvailableError.test.js
Lines 88 to 97 in df6be4e
This can be verified in a simple manner by isolating that test and adding a log line in the
*getAccountSummaries()
resolver, which will log twice for the test run.I don't think this means we need to change anything, just pointing it out as a bit of unexpected behaviour to be aware of.