title: React event processing
body: <p>Consider an edit box. User types some text. There is a key-press handler attached, which does something like:</p>
  
  <pre><code>setState({echo: this.state.echo + event.char})
  </code></pre>
  
  <p>Is it possible that in initial state <code>{echo: “”}</code>, the user types “a” then “b”, React calls <code>onKeyPress(“a”)</code>, which calls <code>setState({echo: “a”})</code>, and then - before setState is actually applied by <code>React - React calls onKeyPress(“b”)</code>?</p>
  
  <p>You see a problem with that, right? <code>OnKeyPress(“b”)</code> will see the same old state <code>{echo: “”}</code> as <code>OnKeyPress(“a”)</code> did, and will issue<code>setState({echo: “”+“b”})</code>, which is <code>setState({echo: “b”})</code> - while we obviously wanted <code>{echo: “ab”}</code></p>
  
  <ul>
  <li>My tests show me that the second event handler does not get called before first <code>setStat</code>e is completely processed. But a few tests may lie, unlike some documented contract.</li>
  <li>I realize that this problem has solutions, like using form <code>setState( state =&gt; …)</code></li>
  <li>But I still want to know: is this situation possible or not. Maybe synthetic event handlers are guaranteed to only be executed when all pending <code>setState</code> processing (caused by previous handler) is done? If so, where can I read some proof of that? A specific location in some manual, or qualified answer posted on the Web… Or, maybe, it’s the opposite that is true - that no such guarantees exist (however if that’s the case, “simple” form of setState is sure to cause bugs and they should not allow this form at all).</li>
  </ul>