-
Notifications
You must be signed in to change notification settings - Fork 46.9k
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
[compiler] Make ref enforcement on by default #30716
Conversation
Summary: The change earlier in this stack makes it less safe to have ref enforcement disabled. This diff enables it by default. [ghstack-poisoned]
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Summary: The change earlier in this stack makes it less safe to have ref enforcement disabled. This diff enables it by default. ghstack-source-id: 341048b4971630bbbda5dc00157fb86826970713 Pull Request resolved: #30716
Summary: The change earlier in this stack makes it less safe to have ref enforcement disabled. This diff enables it by default. [ghstack-poisoned]
Summary: The change earlier in this stack makes it less safe to have ref enforcement disabled. This diff enables it by default. ghstack-source-id: bb58c509352bb4a392a87188b10894fb1cf86eca Pull Request resolved: #30716
expect(defaultConfig.validateNoSetStateInRender).toBe(true); | ||
|
||
const config = parseConfigPragma( | ||
'@enableUseTypeAnnotations @validateRefAccessDuringRender:true @validateNoSetStateInRender:false', | ||
'@enableUseTypeAnnotations @validateRefAccessDuringRender:false @validateNoSetStateInRender:false', |
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.
nit: the idea of this test was to test both the @flag
, @flag:true
, and @flag:false
cases, so maybe choose a different off-by-default flag to use instead
return useCallback(() => { | ||
if (ref != null) { | ||
ref.current(); | ||
} | ||
}, []); |
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.
hmm this actually seems like it should be allowed: this could be returning a callback that is only called in an event/effect
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.
Awesome, i commented earlier in the stack about enabling this by default so we're on the same page. But see comments - i think we're a bit too strict right now and should relax the case of a hook returning a callback which accesses a ref.
Summary: The change earlier in this stack makes it less safe to have ref enforcement disabled. This diff enables it by default. [ghstack-poisoned]
Good call, addressed in 30724 |
Summary: The change earlier in this stack makes it less safe to have ref enforcement disabled. This diff enables it by default. ghstack-source-id: 4dbf7050f5e324027201fc7efee0561554b3eda1 Pull Request resolved: #30716
Summary: The change earlier in this stack makes it less safe to have ref enforcement disabled. This diff enables it by default. [ghstack-poisoned]
Summary: The change earlier in this stack makes it less safe to have ref enforcement disabled. This diff enables it by default. ghstack-source-id: e3d85445f7cd95297832dd4d836edc160fe9c2ef Pull Request resolved: #30716
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.
awesome job
Summary: The change earlier in this stack makes it less safe to have ref enforcement disabled. This diff enables it by default. [ghstack-poisoned]
Summary: The change earlier in this stack makes it less safe to have ref enforcement disabled. This diff enables it by default. ghstack-source-id: d3ab5f1b28b7aed0f0d6d69547bb638a1e326b66 Pull Request resolved: #30716
Summary: The change earlier in this stack makes it less safe to have ref enforcement disabled. This diff enables it by default. ghstack-source-id: d3ab5f1b28b7aed0f0d6d69547bb638a1e326b66 Pull Request resolved: #30716
This change has on the whole exposed lots of potential bugs for us - thanks. The main case where we see alot of non bugs is passing the ref into a custom hook or react hook (useImperitiveHandle). In these cases it seems it usually uses useLayoutEffect and then reads the ref inside useLayoutEffect. should it be relaxed to allow passing refs to hooks? |
Stack from ghstack (oldest at bottom):
Summary:
The change earlier in this stack makes it less safe to have ref enforcement disabled. This diff enables it by default.