4 ms·
> 17.0: Remove componentWillMount, componentWillReceiveProps, and componentWillUpdate . (Only the new “UNSAFE_” lifecycle names will work from this point forwar
by bhj 9y ago
> 17.0: Remove componentWillMount, componentWillReceiveProps, and componentWillUpdate . (Only the new “UNSAFE_” lifecycle names will work from this point forward.)
Wow, I try to use those as little as possible because there's always a bit of a smell, but I suspect there's a lot of code out there that will be getting a second look now. Kudos to the React team for explaining the rationale and migration path(s) in detail. React has consistently made me write better code, however begrudgingly.
- Blackstone4 9y agoWhen I first started using React, I kept trying to use componentWillMount, componentWillReceiveProps, and componentWillUpdate... I kept getting stuck in infinite loops... new prop updates state which re-renders the component which means "new props" updates state which re-renders component etc. Or something like that.... Now my react components are a lot simpler and I don't try anything fancy. The parents tend to handle the data fetching and they pass it down to the children components which are often stateless components. So I only use constructor(props) and render() plus custom functions. It keeps it cleaner but I also have more components as a result. Some of which do very little. So I agree, those functions smell and looked more useful upon first glance than they actually were.
- k__ 9y agoI used them mostly for server side rendering, if I remeber correctly. componentDidMount will fire only on the client and componentWillMount on client and server. Since the server rendered stuff wasn't interactive I could only do a subset of the things the client allowed, so I would do these in componentWillMount and the rest in componentDidMount only on the client.
- danabramov 9y agoIf there’s some specific use case we’re missing in the blog post please let us know! `componentWillMount` is technically equivalent to the constructor so there's nothing you could do on the server you couldn't do in the constructor instead. https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html#other-scenarios https://reactjs.org/blog/2018/03/27/update-on-async-renderin...
- k__ 9y agoI know, but I often avoid meddling with constructors. Passing the right stuff to super etc.
- TheCoelacanth 9y agoNow they just need to do the same for all of the other componentWill* and componentDid* methods /s I guess there are legitimate uses for them, but almost invariably any component I see that uses them turns out to be a buggy POS.