Open ghost opened 6 years ago
Looks better with a diagram)
I don't think you should remove the old methods - those will still be used in legacy code for a long time to come. I think we need to teach these. But I agree that a distinction should be made. I suggest inserting challenges after each and explain that those will be deprecated in React 17+ and explain what the new methods are.
@kevinsmithwebdev I think you are right about not removing them completely. It would be good to mention them, explain that they have been deprecated as of react 16.3, and include a link to the docs. I don't think it's a good idea to have the user use any of these deprecated methods in the challenges though.
I disagree with not teaching componentWilMount, et al. I know it's cool to just focus on the latest version, but there are millions of web sites out there with pre 16.3 React and there will be for years to come. For a few years, there will probably be more work for pre 16.3. Companies don't always run out and upgrade to the latest version - they have a working web site and don't want to spend thousands of dollars paying people to go through and update the code to make it work in the new version.
I agree that it's important to teach the new methods, but I think we need to also teach the old ones and explain the change. In JavaScript, we still teach var
, even though it is largely supplanted by let
and const
. We teach it because they are going to run into it in the real world of coding. Similarly, they are going to be running into those deprecated methods for a long time to come.
My opinion is to remove them if they are being depreciated.
I think there are plenty of resources online that if a person comes across these methods in the future, that they will be fine to learn from those.
I think keeping them in the curriculum just adds material that is a "maybe you will see this" and is no longer fundamental ("you will need to know this").
React is removing them for better alternatives. I think keeping them could also lead to encouraging a bad practice and users thinking they are okay to use in future versions.
I wouldn't say "maybe you'll see this". I'd say "you will definitely see this for at least a decade to come."
They deprecated since 16.3 and will be removed in 17
It is more accurate to say that they will be will be renamed and discouraged in 17. Even then, you can still use the old names and they will transpile into the new names.
From the docs:
Even in version 17, it will still be possible to use them, but they will be aliased with an “UNSAFE_” prefix to indicate that they might cause issues. We have also prepared an automated script to rename them in existing code.
But again, I think this is missing a point about how software exists through versions. When a new version comes out, everyone doesn't stop using the old one and upgrade to the new one. Angular (2) came out out 2014 but a lot of people are still using AngularJS (1). And now Angular 4 is out. All of these exist side by side. Heck, people are still using COBOL code. componentWillMount is going to be showing up in React code for a while time to come.
https://learn.freecodecamp.org/front-end-libraries/react/use-the-lifecycle-method-componentwillmount uses deprecated React methods like:
componentWillMount,
componentWillUpdate,
componentWillReceiveProps
They deprecated since 16.3 and will be removed in 17
Info: https://reactjs.org/blog/2018/03/29/react-v-16-3.html