setState gets aggregated and scheduled, it does not run atomic and immediate, so you can't just issue multiple setState() calls and expect things to work, you either have to wait for the state to update before updating it again, or use an instance variable.
Option 1:
doSomething() {
this.setState({
myarr: []
}, () => { // called by React after the state is updated
this.setState({
myarr: [3]
});
});
}
This is fairly cumbersome and depending on what you're doing, mostly just bad code. The other option is to use a "real" instance variable that you send over as state at moments when you need to.
Option 2:
getInitialState() {
this.mylist = [];
return {
myarr: this.mylist
};
},
...
doSomething() {
this.mylist = [];
for(let i = 0; i < 10; i++) {
this.mylist.push(i);
}
this.setState({
myarr: this.mylist
});
}
Remember that updating the state means you have changed an aspect of your component in a way that requires a rerender, so don't use setState for "intermediate" changes, i.e. changes where a render is not necessary, like clearing the array before refilling it (the state change is the new data, not the intermediate cleared state). Do that stuff separately, and only update the state once you're done.
Option 3:
You could also do this by taking out the state values, running your updates, and then rebinding, without ever building a persistent instance variable:
doSomething {
const list = this.state.myarr;
list.splice(0, list.length);
for (let i = 0; i < 10; i++) {
list.push(i);
}
this.setState({
myarr: list
});
}
The net effect is the same: you only update your UI when your data is in some stable configuration, so if you're calling setState() more than once between renders for the same state key, that's a problem: every setState() call may trigger a render "eventually", and consecutive setState() calls before that happens will override same-named-key updates if you don't wait for them to be processed first.
