7 ms·

Why is setState asynchronous?

136 points by stablemap 9y ago

rootlocus 9y ago
The title should probably mention the technology the question is referring to. This isn't a javascript forum...
- cryptonector 9y ago
  The linked comment is very meaningful and comprehensible even if you're not a web developer (which I'm not). The only word in the title that may not be immediately meaningful is "setState", but the rest is still a huge draw for anyone who has had to deal with async code.
  - halayli 9y ago
    you’re arguing nonsense just for the sake of arguing. if someone hasn’t used react before then the title is meaningless.
    - cryptonector 9y ago
      I haven't used React before and the title definitely grabbed my attention. The linked comment was very informative to me, even though I'm not a UI dev.
- globuous 9y ago
  The url's actually pretty explicit ! (github.com/facebook/react).
admax88q 9y ago
JS is a mess. I think this blog post highlights the frustrating viral nature that is async functions: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
- ocfx 9y ago
  JS is a mess because React is using a concept similar to double buffering to prevent bad rendering? That's all this is, they are batching updates to the DOM before reconciliation to reduce redraws.
- maxxxxx 9y ago
  That's a good article. And yes, async is totally viral. Once you start using it, everything becomes async if you like it or not. I definitely need to study Go and goroutines. They seem to have a better approach.
  - cryptonector 9y ago
    There is no good approach to avoiding asynchrony. There's been nothing new in this department for decades. You have these choices: - async, continuation passing style code - async with delineated continuations to make snippets look synchronous which aren't actually - cooperative multi-tasking (co-routines with async I/O under the covers) - threading (preemtible multitasking) Each one of this choices has its problems, and all can be characterized as where on the spectrum of explicit vs. implicit state keeping you want to be. For example, with threads and co-routines you keep a lot of implicit state in the call stack, whereas with async CPS you make all of the state fully explicit. Async CPS code is the least problematic once you wrap your mind around it, but it does have "mind warp" as a hard requirement. There are times, of course, when your code is very serial, and then you really do benefit from co-routines/threads. For example, PuTTY's implementation of the SSH version exchange, key exchange, and user authentication protocols, is one HUGE C function that is actually running as a co-routine which cooperates with the UI side, with async I/O under the covers. The PuTTY approach is wonderful for that particular case: those parts of the SSH protocols are extremely serial, and the resulting serial-looking code is very very easy on the eyes (so much so that it makes up for the enormity of the function that implements it!). So it pays to be able to reach for co-routines sometimes, but not always, and I'd say not even most of the time. Programmers today simply have to be prepared to deal with everything-is-async codebases, and they should be prepared to create codebases where everything is async from day zero.
ambrop7 9y ago
A (presumably controversial) way to use React is to use only props never state, manage state in your own variables (possibly in a separate "controller" class) and call forceUpdate() when you have changed those variables such that the render would change. This gives me flexibility to structure the code how I want. You can have the separate "controller" classes deal with operations (like API requests) and the "react class" mostly deals with display - it delegates actions to the controller and retrieves data from the controller. This can promote code reuse, notably certain components can share the controller class (not instance) when you have similar logic. As a more general principle, I like react just fine as a way to express the DOM in a functional way and for its magic of figuring out just what parts of the actual DOM must be updated; but I don't really care about how React wants me to write code in other aspects, like where and how I should manage my data.
- GeneralTspoon 9y ago
  Actually, using props instead of state is a pretty common thing to do - it's how redux integrates with React [1] [1] https://redux.js.org/docs/basics/UsageWithReact.html https://redux.js.org/docs/basics/UsageWithReact.html
  - zukzuk 9y ago
    ... but also a very bad idea in practice, as most devs eventually find out. Using the Redux store in lieu of state spreads code that could otherwise be self-contained all over your codebase. It's a good way to make a huge mess and write some very brittle code.
    - always_good 9y ago
      I find that hard to believe. Coupling state with components is exactly what makes React brittle imo.
    - nemothekid 9y ago
      I’ve managed a huge React app with Redux and never came across this - I can’t imagine how your case would come up. Even though we use a single state object, the concerns of a single piece of state tend to be contained in its reducer and component only.
josephorjoe 9y ago
They really should have just named it `queueStateChangeRequest` instead of `setState`, since it does the former and not the latter.

136 points by stablemap 9y ago

rootlocus 9y ago

The title should probably mention the technology the question is referring to. This isn't a javascript forum...

cryptonector 9y ago
The linked comment is very meaningful and comprehensible even if you're not a web developer (which I'm not). The only word in the title that may not be immediately meaningful is "setState", but the rest is still a huge draw for anyone who has had to deal with async code.
- halayli 9y ago
  you’re arguing nonsense just for the sake of arguing. if someone hasn’t used react before then the title is meaningless.
  - cryptonector 9y ago
    I haven't used React before and the title definitely grabbed my attention. The linked comment was very informative to me, even though I'm not a UI dev.
globuous 9y ago
The url's actually pretty explicit ! (github.com/facebook/react).

admax88q 9y ago

JS is a mess. I think this blog post highlights the frustrating viral nature that is async functions: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

ocfx 9y ago
JS is a mess because React is using a concept similar to double buffering to prevent bad rendering? That's all this is, they are batching updates to the DOM before reconciliation to reduce redraws.
maxxxxx 9y ago
That's a good article. And yes, async is totally viral. Once you start using it, everything becomes async if you like it or not. I definitely need to study Go and goroutines. They seem to have a better approach.
- cryptonector 9y ago
  There is no good approach to avoiding asynchrony. There's been nothing new in this department for decades. You have these choices: - async, continuation passing style code - async with delineated continuations to make snippets look synchronous which aren't actually - cooperative multi-tasking (co-routines with async I/O under the covers) - threading (preemtible multitasking) Each one of this choices has its problems, and all can be characterized as where on the spectrum of explicit vs. implicit state keeping you want to be. For example, with threads and co-routines you keep a lot of implicit state in the call stack, whereas with async CPS you make all of the state fully explicit. Async CPS code is the least problematic once you wrap your mind around it, but it does have "mind warp" as a hard requirement. There are times, of course, when your code is very serial, and then you really do benefit from co-routines/threads. For example, PuTTY's implementation of the SSH version exchange, key exchange, and user authentication protocols, is one HUGE C function that is actually running as a co-routine which cooperates with the UI side, with async I/O under the covers. The PuTTY approach is wonderful for that particular case: those parts of the SSH protocols are extremely serial, and the resulting serial-looking code is very very easy on the eyes (so much so that it makes up for the enormity of the function that implements it!). So it pays to be able to reach for co-routines sometimes, but not always, and I'd say not even most of the time. Programmers today simply have to be prepared to deal with everything-is-async codebases, and they should be prepared to create codebases where everything is async from day zero.

ambrop7 9y ago

A (presumably controversial) way to use React is to use only props never state, manage state in your own variables (possibly in a separate "controller" class) and call forceUpdate() when you have changed those variables such that the render would change. This gives me flexibility to structure the code how I want. You can have the separate "controller" classes deal with operations (like API requests) and the "react class" mostly deals with display - it delegates actions to the controller and retrieves data from the controller. This can promote code reuse, notably certain components can share the controller class (not instance) when you have similar logic. As a more general principle, I like react just fine as a way to express the DOM in a functional way and for its magic of figuring out just what parts of the actual DOM must be updated; but I don't really care about how React wants me to write code in other aspects, like where and how I should manage my data.

GeneralTspoon 9y ago
Actually, using props instead of state is a pretty common thing to do - it's how redux integrates with React [1] [1] https://redux.js.org/docs/basics/UsageWithReact.html https://redux.js.org/docs/basics/UsageWithReact.html
- zukzuk 9y ago
  ... but also a very bad idea in practice, as most devs eventually find out. Using the Redux store in lieu of state spreads code that could otherwise be self-contained all over your codebase. It's a good way to make a huge mess and write some very brittle code.
  - always_good 9y ago
    I find that hard to believe. Coupling state with components is exactly what makes React brittle imo.
  - nemothekid 9y ago
    I’ve managed a huge React app with Redux and never came across this - I can’t imagine how your case would come up. Even though we use a single state object, the concerns of a single piece of state tend to be contained in its reducer and component only.

josephorjoe 9y ago

They really should have just named it `queueStateChangeRequest` instead of `setState`, since it does the former and not the latter.