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

react-router-v3: Add UNSAFE_ prefixes to deprecated lifecycle methods #6883

Merged
merged 4 commits into from
Aug 23, 2019

Conversation

liuyenwei
Copy link

React 16.9 starts to warn whenever componentWillMount , componentWillReceiveProps, or componentWillUpdate are used without the UNSAFE_ prefixes.

This PR aims to address this by dynamically appending the UNSAFE_ prefixes based on React version. The main motivation for doing this is so v3 does not break compatibility with consumers who are using React < 16.3 that don't support the prefixed lifecycled methods.

Note: I only updated the lifecycle methods for the exported modules, not the ones in the examples.

modules/ContextUtils.js Outdated Show resolved Hide resolved
modules/ContextUtils.js Outdated Show resolved Hide resolved
@timdorr
Copy link
Member

timdorr commented Aug 22, 2019

Any thoughts on this approach vs reduxjs/react-redux#1383?

@liuyenwei
Copy link
Author

Any thoughts on this approach vs reduxjs/react-redux#1383?

Don't feel super strongly here, but my thoughts around this:

  • semver checking felt more explicit to me vs testing for existence of a corresponding features introduced in 16.3
  • syntax wise, i think i actually like just leaving the original declaration as-is and then updating the prototype methods below.

thoughts? happy to make changes to align the two approaches 👍

@timdorr
Copy link
Member

timdorr commented Aug 22, 2019

semver checking felt more explicit to me vs testing for existence of a corresponding features introduced in 16.3

I would prefer if we could do feature detection on this, but I agree version checking is the next best option.

syntax wise, i think i actually like just leaving the original declaration as-is and then updating the prototype methods below.

Yeah, it makes it easier to see where it happens. Also, I think it might transpile to smaller code.

@elyobo
Copy link
Contributor

elyobo commented Aug 22, 2019

Yeah, fundamentally they end up with the same behaviour and the differences are minor.

I'm feature checking, but (as @bishwei correctly points out) I'm checking for a feature that happened to come in the same release not the actual feature that really matters in this case (support for UNSAFE_ lifecycle methods) because I couldn't easily see how to do that. I'm not sure that it's any better than checking the semver, which is what I did at first - although I didn't realise that parseFloat would return anything other than NaN for a semver string (the MDN docs need a small update there) so had pulled in semver to parse it which seemed excessive.

Inline vs later prototype modification I don't mind either way; inline makes it clear that that function name might be modified later when reading the initial definition, if that's important to know for some reason, prototype modification groups all of the modifications in one place and makes a infinitesimally smaller number of comparisons :D If there's a significant difference in transpilation size, maybe that should be the guide - try it and see?

@liuyenwei
Copy link
Author

@timdorr, changes made to consolidate the renaming of the methods!

@elyobo
Copy link
Contributor

elyobo commented Aug 22, 2019

LGTM; if you're happy with this approach @timdorr then I'll update reduxjs/react-redux#1383 to be consistent in implementation and hopefully we can get that merged too.

Copy link
Contributor

@pshrmn pshrmn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The module changes look fine to me. The React version doesn't really need to be bumped, but I don't think it hurts anything either.

@@ -15,15 +15,15 @@ function makeContextName(name) {
return `@@contextSubscriber/${name}`
}

const prefixUnsafeLicycleMethods = parseFloat(React.version) >= 16.3
const prefixUnsafeLifeycleMethods = parseFloat(React.version) >= 16.3
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgot a c. Lifeycle -> Lifecycle

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😅 good catch, thanks

@timdorr timdorr merged commit 8f2830d into remix-run:v3 Aug 23, 2019
@timdorr
Copy link
Member

timdorr commented Aug 23, 2019

I'll work on getting this out shortly.

@tomspeak
Copy link

Is there a rough plan for when this will be released?

@timdorr
Copy link
Member

timdorr commented Sep 16, 2019

It was released in 3.2.4: https:/ReactTraining/react-router/releases/tag/v3.2.4

@tomspeak
Copy link

Ah. I have misread this thread, sorry. I seem to be getting this issue on v5.0.1, but it must be due to another package.

@timdorr
Copy link
Member

timdorr commented Sep 16, 2019

Yes, 5.0 doesn't have this problem.

@@ -14,13 +15,15 @@ function makeContextName(name) {
return `@@contextSubscriber/${name}`
}

const prefixUnsafeLifecycleMethods = parseFloat(React.version) >= 16.3

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@timdorr as I mentioned over in reduxjs/react-redux#1383 (comment) , this parses the latest version of React (16.10.1) as 16.1, so this is broken.

@lock lock bot locked as resolved and limited conversation to collaborators Nov 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants