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
Currently ReactInternals.addUserTimingListener enables logging to the User Timing API inside a setTimeout.
However, for the use case of building a profiling tool where instrumentation is turned off most
of the time to avoid overhead, then randomly turned on for a period to take a sample, it would be ideal to be able to enable this logging synchronously (eg. turn it on at the start of a callstack and turn it off again at the end of the synchronous stack).
This is complicated by the fact that the enabled state of the logging should not be toggled inside a React callstack. As the profiler would have control over when the toggling happens, I think it would be fine to throw an error/return false/something like that if the logging was toggled while inside a React stack, allowing the profiler to try again later.
In fact, if the toggling was synchronous the profiler cp avoid this error by doing the toggling at the start and end of an event handler/setTimeout/reqAnimFrame etc which would ensure that we are not inside synchronous call into React (though I'm not quite sure what the implications of Fiber are here; would React async rendering mean that we could re-enter from the event loop at a time when this toggling should not happen?).
Alternatively the toggling could happen 'async but just later in the same React stack' (like setState). In this case the code requesting the toggling would probably need some kind of callback to know that toggling happened so it can keep track of whether React's logging is on or off. However this variant seems like it would be more complicated to implement, and for our use case I don't think it's any more useful than having the toggling just fail in a recoverable way.
though I'm not quite sure what the implications of Fiber are here; would React async rendering mean that we could re-enter from the event loop at a time when this toggling should not happen
I think it could re-enter from requestAnimationFrame, requestIdleCallback, or setTimeout. (Depends on how we implement the polyfill.)
Currently ReactInternals.addUserTimingListener enables logging to the User Timing API inside a
setTimeout
.However, for the use case of building a profiling tool where instrumentation is turned off most
of the time to avoid overhead, then randomly turned on for a period to take a sample, it would be ideal to be able to enable this logging synchronously (eg. turn it on at the start of a callstack and turn it off again at the end of the synchronous stack).
This is complicated by the fact that the enabled state of the logging should not be toggled inside a React callstack. As the profiler would have control over when the toggling happens, I think it would be fine to throw an error/return false/something like that if the logging was toggled while inside a React stack, allowing the profiler to try again later.
In fact, if the toggling was synchronous the profiler cp avoid this error by doing the toggling at the start and end of an event handler/setTimeout/reqAnimFrame etc which would ensure that we are not inside synchronous call into React (though I'm not quite sure what the implications of Fiber are here; would React async rendering mean that we could re-enter from the event loop at a time when this toggling should not happen?).
Alternatively the toggling could happen 'async but just later in the same React stack' (like setState). In this case the code requesting the toggling would probably need some kind of callback to know that toggling happened so it can keep track of whether React's logging is on or off. However this variant seems like it would be more complicated to implement, and for our use case I don't think it's any more useful than having the toggling just fail in a recoverable way.
cc @gaearon
The text was updated successfully, but these errors were encountered: