Add ReactVersion to SchedulingProfiler render scheduled marks

[kartikcho]

Summary

These SchedulingProfiler marks are currently being used by our experimental concurrent mode profiler tool.

Context: Brian at MLH-Fellowship#5 (comment):

Since we are actively changing the "lanes" implementation and what the semantic value of a given lane is (e.g. #19287) it would be helpful for us to encode some info in our profile that lets us match this information up later.

I had been thinking about eventually encoding what the lanes ranges are, so we could display some meaningful label in the profiler, but maybe that would be a hassle and for now- we could get away with just marking the version of React the profiling data corresponds to. This would let us at least manually match the lanes up later if we wanted to dig in deeper.

We only add version strings to the render scheduled marks as these marks do not appear often and would thus provide the profiler with information it needs without unnecessarily bloating the profiles.

There is a known limitation to this approach: because renders are not scheduled often (generally only on page load), it is possible to generate profiles that do not contain React version numbers. Ideally, we'd want to log ReactVersion when we detect the start of a profiling session, but as far as we can tell this is currently not possible without integrating with Chrome DevTools.

Resolves MLH-Fellowship#35, and unblocks MLH-Fellowship/scheduling-profiler-prototype#73

Test Plan

yarn test: tests for SchedulingProfiler have been updated. The new render scheduled marks look like this: --schedule-render-1-17.0.0-alpha.0.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit f0c6d10:

Sandbox	Source
React	Configuration

[sizebot]

No significant bundle size changes to report.

Size changes (experimental)

Generated by 🚫 dangerJS against f0c6d10

[sizebot]

No significant bundle size changes to report.

Size changes (stable)

Generated by 🚫 dangerJS against f0c6d10

[bvaughn]

Hey @kartikcho!

I think adding the React version to our profiling data is a good change 👍 so long as the profiler UI degrades gracefully when the version isn't detected.

I know I mentioned the idea of adding it to render-scheduled initially, since that event isn't logged often, but then after thinking about it a bit more– I think that event is typically only logged once (at the start of the page), so adding it there doesn't seem much better than logging it on its own during module-init. Maybe we should do that instead?

What do you think?

[kartikcho]

I agree, logging React version on it's own seems to be a better choice. @taneliang what do you think?

[taneliang]

Hey @bvaughn, thanks for the reply!

so long as the profiler UI degrades gracefully when the version isn't detected

We haven't updated the profiler UI to display React versions yet, but when we do we'll definitely keep this in mind. We may actually also want to handle multiple React versions in a single profile?

I think that event is typically only logged once (at the start of the page), so adding it there doesn't seem much better than logging it on its own during module-init. Maybe we should do that instead?

This makes sense, and it'll be slightly cleaner since we won't have to overload the render scheduled mark.

I don't actually know where we can add a module-init mark, but I'll take a look later today and maybe we can discuss this on our call later as well.

[bvaughn]

We may actually also want to handle multiple React versions in a single profile?

I think this is probably a case we should not try to support. Interleaved profiles (from multiple Reacts) would not be guaranteed to work properly unless we did something like generate a unique token at the start of a session and log it along with each mark (to distinguish between the different Reacts). I don't think this is is a common enough use case to be worth supporting.

I don't actually know where we can add a module-init mark, but I'll take a look later today and maybe we can discuss this on our call later as well.

Just in the body of the module, e.g. right after we detect and set supportsUserTiming.

[taneliang]

Interleaved profiles (from multiple Reacts) would not be guaranteed to work properly

Oh yes, that's a great point, didn't think of that.

Just in the body of the module

Yeah, I just realized we could do this 😆 On it!

[bvaughn]

👍