You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While playing around with a potential implementation for the idea proposed in #562 (comment), I discovered a bug that occurs if the attribution version of onINP() gets called multiple times on the same page.
While not a common use case, there may be reasons why a user might want to do this (e.g. to allow for multiple configurations to run simultaneously), and currently it does not work because the when onINP() is called twice (or more times), multiple PerformanceObserver objects are created and the entryPreProcessingCallbacks functions—which are effectively global—get called for both sets of dispatched entries.
To prevent this, we could scope the INP attribution logic to within the closure of the onINP() function, so multiple calls to onINP() get their own set of entryPreProcessingCallbacks functions.
Something like this would also be necessary if we wanted to allow users to pass in custom selector generation logic (as discussed in #562 (comment)) since in that case the entryPreProcessingCallbacks functions would need access to the opts object passed to onINP().
The text was updated successfully, but these errors were encountered:
While playing around with a potential implementation for the idea proposed in #562 (comment), I discovered a bug that occurs if the attribution version of
onINP()
gets called multiple times on the same page.While not a common use case, there may be reasons why a user might want to do this (e.g. to allow for multiple configurations to run simultaneously), and currently it does not work because the when
onINP()
is called twice (or more times), multiplePerformanceObserver
objects are created and theentryPreProcessingCallbacks
functions—which are effectively global—get called for both sets of dispatched entries.To prevent this, we could scope the INP attribution logic to within the closure of the
onINP()
function, so multiple calls toonINP()
get their own set ofentryPreProcessingCallbacks
functions.Something like this would also be necessary if we wanted to allow users to pass in custom selector generation logic (as discussed in #562 (comment)) since in that case the
entryPreProcessingCallbacks
functions would need access to theopts
object passed toonINP()
.The text was updated successfully, but these errors were encountered: