Skip to content
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

Merged
merged 5 commits into from
Aug 16, 2024

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]
Copy link

vercel bot commented Aug 15, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
react-compiler-playground ✅ Ready (Inspect) Visit Preview 💬 Add feedback Aug 16, 2024 5:16pm

mvitousek added a commit that referenced this pull request Aug 15, 2024
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]
mvitousek added a commit that referenced this pull request Aug 15, 2024
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',
Copy link
Contributor

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

Comment on lines 11 to 15
return useCallback(() => {
if (ref != null) {
ref.current();
}
}, []);
Copy link
Contributor

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

Copy link
Contributor

@josephsavona josephsavona left a 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]
@mvitousek
Copy link
Contributor Author

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.

Good call, addressed in 30724

mvitousek added a commit that referenced this pull request Aug 16, 2024
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]
mvitousek added a commit that referenced this pull request Aug 16, 2024
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
Copy link
Contributor

@josephsavona josephsavona left a 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]
mvitousek added a commit that referenced this pull request Aug 16, 2024
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
@mvitousek mvitousek merged commit c6183a1 into gh/mvitousek/28/base Aug 16, 2024
19 checks passed
mvitousek added a commit that referenced this pull request Aug 16, 2024
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
@mvitousek mvitousek deleted the gh/mvitousek/28/head branch August 16, 2024 17:29
@lukpsaxo
Copy link

lukpsaxo commented Sep 4, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants