From 8c27453c7027d5c9798c5e081f52339bafcf841a Mon Sep 17 00:00:00 2001 From: Brian Vaughn Date: Fri, 8 Dec 2017 14:29:00 -0800 Subject: [PATCH] Added a note about the prefix --- text/0000-static-lifecycle-methods.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/text/0000-static-lifecycle-methods.md b/text/0000-static-lifecycle-methods.md index 3059e019..b5dcdb35 100644 --- a/text/0000-static-lifecycle-methods.md +++ b/text/0000-static-lifecycle-methods.md @@ -193,21 +193,21 @@ React does not call this method before the intial render/mount and so it is not ### `componentWillMount` -This method will log a deprecation warning in development mode recommending that users use the new static `prefetch` method instead. It will be removed entirely in version 17. +This method will log a deprecation warning in development mode recommending that users either rename to `unsafe_componentWillMount` or use the new static `prefetch` method instead. It will be removed entirely in version 17. ### `componentWillUpdate` -This method will log a deprecation warning in development mode recommending that users use the new static `prefetch` method instead. It will be removed entirely in version 17. +This method will log a deprecation warning in development mode recommending that users either rename to `unsafe_componentWillUpdate` or use the new static `prefetch` method instead. It will be removed entirely in version 17. ### `componentWillReceiveProps` -This method will log a deprecation warning in development mode recommending that users use the new static `deriveStateFromProps` method instead. It will be removed entirely in version 17. +This method will log a deprecation warning in development mode recommending that users either rename to `unsafe_componentWillReceiveProps` or use the new static `deriveStateFromProps` method instead. It will be removed entirely in version 17. # Drawbacks The current component lifecycle hooks are familiar and used widely. This proposed change will introduce a lot of churn within the ecosystem. I hope that we can reduce the impact of this change through the use of codemods, but it will still require a manual review process and testing. -This change is **not backwards compatible**. It will require library maintainers to drop support for older versions of React in order to support the future component API. Unfortunately, I believe this is unavoidable in order to safely transition to an async-compatible world. +This change is **not fully backwards compatible**. Libraries will need to drop support for older versions of React n order to use the new, static API. Unfortunately, I believe this is unavoidable in order to safely transition to an async-compatible world. # Alternatives @@ -229,7 +229,9 @@ Begin by reaching out to prominent third-party library maintainers to make sure Assuming we move forward with the proposal, release (at least one) minor 16.x update to add deprecation warnings for the legacy lifecycles and inform users to use the new static methods instead. We'll then cordinate with library authors to ensure they have enough time to migrate to the new API in advance of the major release that drops support for the legacy lifecycles. -We will also provide codemods to assist with the migration, although given the nature of the change, codemods will be insufficient to handle all cases. Manual verification will be required. +We will provide a codemod to rename the deprecated lifecycle hooks with the new `unsafe_` prefix. + +We will also provide codemods to assist with the migration to static methods, although given the nature of the change, codemods will be insufficient to handle all cases. Manual verification will be required. # How we teach this