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.
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.
Feels sad to accommodate an inadequacy of a test-env-specific library, given that this API is supported in all major browsers: https://caniuse.com/mdn-api_performance_getentriesbytype
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 agree. However it's a guard, rather than a polyfill, or holding ourselves back in using new features or syntax. So I'm comfortable with this. We've a few cases of this in the library.
But let's see if @philipwalton agrees!
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.
Optional chaining could make this not so bad, but in general if you're using jsdom for testing, you'll be mocking out a bunch of stuff anyways and it shouldn't generally be put on the library to do that.
Nothing will work in jsdom anyways, looks like there's no PerformanceObservers either, so I wonder if the tester should just short circuit it completely.
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.
For those we wrap it in a try/catch anyway:
https://github.com/GoogleChrome/web-vitals/blob/v5/src/lib/observe.ts
Hence why they didn’t cause a problem.
For TTFB however we just call it as it doesn’t need a PerformanceObserver.
I don’t think the intent is to test the library in JSDOM, it’s more the whole page is being loaded in that (including this script) and it hits this error.
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.
Oh and I tried optional chaining initially and still complained
getEntriesByTyoe
wasn’t a function. Because performance does exist but not much under it. Open to ideas on how to implement this better if you know some better optional chaining syntax for that? For now I just reverted back to what we had in v4.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.
right, but I guarantee this isn't the only thing broken in jsdom and they already have a "set up the mocks" section somewhere because there's always something (usually several things) that need to be mocked out
performance.getEntriesByType?.('navigation')[0]
should workThere 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.
Oh that worked! Thank you. Updated in 16f4a51