setState() callback function: potential confusion of call order

This paragraph from the React.Component reference page:

setState() does not always immediately update the component. It may batch or defer the update until later. This makes reading this.state right after calling setState() a potential pitfall. Instead, use componentDidUpdate or a setState callback (setState(updater, callback)), either of which are guaranteed to fire after the update has been applied.

can create the impression that instead of doing:

this.setState({ value: 5 });
console.log(this.state.value); // => not necessarily 5

you can use the callback function to safely read the state back:

this.setState({ value: 5 }, () => console.log(this.state.value)); // => "guaranteed" 5

(especially if you draw a parallel between the callback function and the updater function)

and it may actually work in some cases where there's no setState batching, but as more calls get batched in the future, these constructs may generate unintended side-effects.

Instead, we could clarify that all callback functions for a batch of setState() calls get called after the entire batch has been processed.

Bắt đầu với phần setState của trang tham chiếu React.Component được liên kết trong issue. Xem lại cách diễn đạt về callbacks và batching, sau đó cập nhật để thời điểm callback được thực thi và state có sẵn sau một batch trở nên rõ ràng; được xem là hoàn tất khi các ví dụ không thể khiến người đọc hiểu rằng một callback chỉ quan sát bản cập nhật riêng lẻ của nó.