6 ms·
On antipatterns: > setState() in componentWillMount() componentWillMount() is an anti-pattern. It is not a true lifecycle hook. It is invoked on the server, u
by steve_taylor 9y ago
On antipatterns:
> setState() in componentWillMount()
componentWillMount() is an anti-pattern. It is not a true lifecycle hook. It is invoked on the server, unlike componentDidMount and friends. Anything you do here can, and perhaps should, be done in the constructor.
> Mutating State without setState()
handleClick() {
// BAD: We mutate state here
this.state.items.push('lorem');
this.setState({
items: this.state.items
});
}
There's no explanation as to why this is bad, just that it's bad and you shouldn't do it. Because.
The real reason, in this particular example, is that any lifecycle hooks that rely on comparing two consecutive versions of the state will not work, because the older version of the state will have been mutated.
> Using indexes as keys... Bad... This limits the optimizations that React can do.
> Good... React would be able to reorder elements without needing to reevaluate them as much.
This isn't any incentive at all. I don't do premature optimizations and so I'd happily use key={index} if optimization was the only issue and performance didn't suck.
The real incentive to use a value that uniquely identifies the entity being rendered as the key, rather than an index, is to prevent the representation of entities from being removed and added back to the DOM, so I can animate their addition and removal, via CSS transitions, when they are actually added and removed. Using the index as the key would make the wrong elements animate. Also, I wouldn't want certain elements to unnecessarily go through the end of their lifecycle only to be created again, especially if their lifecycle hooks are tied to various side effects (e.g. API endpoints being called).
- AnkhMorporkian 9y agoI mildly disagree. componentWillMount() is slightly superior to the constructor, though only for very specific situations[0]. I would agree that for the vast majority of people who use ES6, the difference basically doesn't exist, but there is a real reason to use componentWillMount instead of the constructor. 0: https://github.com/reactjs/react-redux/issues/129 https://github.com/reactjs/react-redux/issues/129 Edit: You might call dispatching in a constructor an anti-pattern (or having any side-effects at all), but quite a few people do it and it can cause very subtle bugs that aren't entirely reproducible.
- steve_taylor 9y agoYeah, if you dispatch in a constructor and the effect is synchronous, it's going to setState somewhere and React will complain, whereas if you do it from componentWillMount, maybe React won't complain, but I'm not sure. My understanding is that componentWillMount was needed for React.createClass, but not so much ES6 classes. It seems a bit weird to be calling setState on a component within the context of another component being created. As far as I'm concerned, setState should only ever be called from an event handler, such as user input, an endpoint returning a response, or a timer event.
- AnkhMorporkian 9y agoI'm not sure how familiar with it you are, but that's kinda a result of flux/redux architecture. There's a global state that things are passed props to. If there is some change triggered as the result of a component being mounted, say a globalish "there's now a tooltip active", that may modify components including the component that triggered the change. That's probably a simplistic example, but it really does happen.