-
Notifications
You must be signed in to change notification settings - Fork 47k
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
Enable the StrictEffects flag for OSS builds #21590
Conversation
@@ -25,7 +25,7 @@ export const debugRenderPhaseSideEffectsForStrictMode = __DEV__; | |||
|
|||
// Helps identify code that is not safe for planned Offscreen API and Suspense semantics; | |||
// this feature flag only impacts StrictEffectsMode. | |||
export const enableStrictEffects = false; | |||
export const enableStrictEffects = true; |
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.
export const enableStrictEffects = true; | |
export const enableStrictEffects = __DEV__; |
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 could do this but there's a small inconsistency in that the WWW version re-exports a GK which does not have a DEV check. I'd rather have them all consistent. Currently I think we always check for __DEV__
in the source anyway before any behavioral changes. So I'd propose either:
- Keep it
true
- Make it
__DEV__
and change WWW feature flag to be__DEV__ && FeatureFlagsWWW.enableStrictEffects
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 it makes more sense to compare to other flags within this feature flags file rather than www. So this would be more like debugRenderPhaseSideEffectsForStrictMode
right above it.
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.
Currently I think we always check for
__DEV__
in the source anyway before any behavioral changes.
Yeah, but this is to enable static dead code elimination in production builds even if there's a dynamic flag (like in www). I think the feature flags still generally use __DEV__
or __PROFILING__
to be 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 it makes more sense to compare to other flags within this feature flags file rather than www.
I'm thinking of a situation where we add some behavior difference in the source without checking __DEV__
before it (by mistake). Then, if WWW and OSS flags diverge in this way, you'd see the different behavior in production on WWW than in production in OSS. That seems like a risky divergence.
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.
Then let's change the OSS www export too.
There's good reason to keep the extra static __DEV__
wrapper (mentioned above) and I think there's also value in keeping the feature flags more scoped/explicit about DEV-only features.
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.
Whoops.
Comparing: d75105f...187567b Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
This failure is curious:
That test has |
PR #20639 landed "strict effects" for new root API only, but when #20849 introduced strict mode levels, it looks like the new root check got changed the check from (workInProgress.mode & (BlockingMode | ConcurrentMode)) !== NoMode to (workInProgress.mode & StrictEffectsMode) !== NoMode I don't remember if this was intentional, although maybe it was since the new level required an explicit opt-in (and wouldn't be rolled out to pre-existing strict trees)? |
#21591 should correct the above issue and fix the failing tests in this branch. |
Now that #21591 has landed, we should be good to rebase and land this one! |
Since you're off today I'm going to go ahead and take up the two action items left over from this PR with #21597 |
Seems like an omission. Are there more we should enable? Also, is it ok to land this to main now, or do we still plan to cut minors from main?
TODO:
render
?)