Turn on string ref deprecation warning for everybody (codemoddable) #25334
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
eps1lon
force-pushed
the
forwardRef/deprecate-string-refs
branch
2 times, most recently
from
7c58a47
to
e93410f
Compare
This was referenced Oct 2, 2022
eps1lon
changed the title
```bash # in react-codemod fork $ ./bin/react-codemod.js --parser flow string-refs $REACT_FORK All done. Results: 1 errors 1876 unmodified 0 skipped 32 ok # in react fork $ yarn prettier-all $ yarn lint --fix
eps1lon
force-pushed
the
forwardRef/deprecate-string-refs
branch
from
e93410f
to
e19c22c
Compare
|
I think the move here is to always initialize a new object for classes. The object pooling is a micro-optimization that doesn't matter in the grand scheme of things. |
sebmarkbage
added a commit
that referenced
this pull request
Nov 16, 2022
This micro-optimization never made sense and less so now that they're rare. This still initializes the class with a shared immutable object in the constructor - which is also what createClass() does. Then we override it during mount. This is done in case someone messes up the initialization of the super() constructor for example, which was more common in polyfills. This change means that if a ref is initialized during the constructor itself it wouldn't be lazily initialized but that's not user code that does it, it's React so that shouldn't happen. This makes string refs codemoddable as described in. #25334
sebmarkbage
pushed a commit
that referenced
this pull request
Nov 17, 2022
…e) (#25383) ## Summary Alternate to #25334 without any prod runtime changes i.e. the proposed codemod in https://github.com/reactjs/rfcs/blob/createlement-rfc/text/0000-create-element-changes.md#deprecate-string-refs-and-remove-production-mode-_owner-field would not work. ## How did you test this change? - [x] CI - [x] `yarn test` with and without `warnAboutStringRefs`
|
Replaced by #25383 |
mofeiZ
pushed a commit
to mofeiZ/react
that referenced
this pull request
Nov 17, 2022
This micro-optimization never made sense and less so now that they're rare. This still initializes the class with a shared immutable object in the constructor - which is also what createClass() does. Then we override it during mount. This is done in case someone messes up the initialization of the super() constructor for example, which was more common in polyfills. This change means that if a ref is initialized during the constructor itself it wouldn't be lazily initialized but that's not user code that does it, it's React so that shouldn't happen. This makes string refs codemoddable as described in. facebook#25334
mofeiZ
pushed a commit
to mofeiZ/react
that referenced
this pull request
Nov 17, 2022
…e) (facebook#25383) ## Summary Alternate to facebook#25334 without any prod runtime changes i.e. the proposed codemod in https://github.com/reactjs/rfcs/blob/createlement-rfc/text/0000-create-element-changes.md#deprecate-string-refs-and-remove-production-mode-_owner-field would not work. ## How did you test this change? - [x] CI - [x] `yarn test` with and without `warnAboutStringRefs`
rickhanlonii
pushed a commit
that referenced
this pull request
Dec 3, 2022
This micro-optimization never made sense and less so now that they're rare. This still initializes the class with a shared immutable object in the constructor - which is also what createClass() does. Then we override it during mount. This is done in case someone messes up the initialization of the super() constructor for example, which was more common in polyfills. This change means that if a ref is initialized during the constructor itself it wouldn't be lazily initialized but that's not user code that does it, it's React so that shouldn't happen. This makes string refs codemoddable as described in. #25334
rickhanlonii
pushed a commit
that referenced
this pull request
Dec 3, 2022
…e) (#25383) ## Summary Alternate to #25334 without any prod runtime changes i.e. the proposed codemod in https://github.com/reactjs/rfcs/blob/createlement-rfc/text/0000-create-element-changes.md#deprecate-string-refs-and-remove-production-mode-_owner-field would not work. ## How did you test this change? - [x] CI - [x] `yarn test` with and without `warnAboutStringRefs`
jerrydev0927
added a commit
to jerrydev0927/react
that referenced
this pull request
Jan 5, 2024
This micro-optimization never made sense and less so now that they're rare. This still initializes the class with a shared immutable object in the constructor - which is also what createClass() does. Then we override it during mount. This is done in case someone messes up the initialization of the super() constructor for example, which was more common in polyfills. This change means that if a ref is initialized during the constructor itself it wouldn't be lazily initialized but that's not user code that does it, it's React so that shouldn't happen. This makes string refs codemoddable as described in. facebook/react#25334
jerrydev0927
added a commit
to jerrydev0927/react
that referenced
this pull request
Jan 5, 2024
…e) (#25383) ## Summary Alternate to facebook/react#25334 without any prod runtime changes i.e. the proposed codemod in https://github.com/reactjs/rfcs/blob/createlement-rfc/text/0000-create-element-changes.md#deprecate-string-refs-and-remove-production-mode-_owner-field would not work. ## How did you test this change? - [x] CI - [x] `yarn test` with and without `warnAboutStringRefs`
acdlite
pushed a commit
that referenced
this pull request
Apr 16, 2024
…e) (#25383) ## Summary Alternate to #25334 without any prod runtime changes i.e. the proposed codemod in https://github.com/reactjs/rfcs/blob/createlement-rfc/text/0000-create-element-changes.md#deprecate-string-refs-and-remove-production-mode-_owner-field would not work. ## How did you test this change? - [x] CI - [x] `yarn test` with and without `warnAboutStringRefs`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
For reactjs/rfcs@createlement-rfc/text/0000-create-element-changes.md#deprecate-string-refs-and-remove-production-mode-_owner-field
Enable
warnAboutStringRefsfor every release.I adjusted the warning logic to not also appear in other cases where we already warn/throw (e.g. function components cannot be given refs).
For the
string-refscodemodto work, we now have to lazily initialize
this.refsfor every function ref.Alternatively we could do
But this gets increasingly difficult since we now have to add an import and global initializer instead of only adjust the local ref.
Or we always eagerly initialize
this.refswhen constructiong class instances.Or we don't add any codemod: #25383
How did you test this change?