In 10.0.0-alpha.2, state does not set properly from componentWillMount. It seems this has been experienced by others in the past in componentWillReceiveProps. Here's a simple test case:
export class TestComponent extends Component {
//This does not work:
componentWillMount() {
this.setState({message:"componentWillMount"});
}
/*
//This works:
componentDidMount() {
this.setState({message:"componentDidMount"});
}
*/
render() {
return <p>State came through from {this.state.message || 'nothing =('}</p>;
}
}
if (isNew) {
if (newType.getDerivedStateFromProps == null && c.componentWillMount != null) c.componentWillMount();
if (c.componentDidMount != null) mounts.push(c);
}
else {
if (newType.getDerivedStateFromProps == null && force == null && c.componentWillReceiveProps != null) {
c.componentWillReceiveProps(newVNode.props, cctx);
s = c._nextState || c.state;
}
if (!force && c.shouldComponentUpdate != null && c.shouldComponentUpdate(newVNode.props, s, cctx) === false) {
c.props = newVNode.props;
c.state = s;
c._dirty = false;
break outer;
}
if (c.componentWillUpdate != null) {
c.componentWillUpdate(newVNode.props, s, cctx);
}
}
I'm not an official member of preact, but I've been learning about their source code
Above is the procedure of executing the componentWillMount function in the source code
Because the variables of s are not updated after the componentWillMount function is executed
Please forgive my English, I am Chinese
Looks like something @mochiya98 is an expert on :tada:
Preact X [10.0.0-alpha.2] https://codesandbox.io/s/n05048yw20
Preact [8.4.2] https://codesandbox.io/s/72k584y111
React [16.8.3] https://codesandbox.io/s/zr1qw8p13p
@marvinhagemeister
if (newType.getDerivedStateFromProps == null && c.componentWillMount != null) {
c.componentWillMount();
s = c._nextState || c.state;
}
Can it be solved?
probably so.
but i... i think there is a better way to solve these problems. maybe we do not need s.
let me think about it.
Is Preact keeping the deprecated[1] React API?
Every componentWill* was deprecated a year (yay, exactly one year) ago and is supposed to be removed in v17.
1: https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html
We'll likely keep them around until they are completely removed in react. We still need them for all UNSAFE_* methods in compat which are just aliased to the unprefixed lifecycle methods. They need to be called in the correct order inside the diff and that's why we don't gain any size benefits until they are removed completely.
Most helpful comment
probably so.
but i... i think there is a better way to solve these problems. maybe we do not need
s.let me think about it.