4 ms·

On the contrary: Redux's insistence on serializable events and side effect-free reducers makes debugging these pernicious "state update" ordering issues, which

On the contrary: Redux's insistence on serializable events and side effect-free reducers makes debugging these pernicious "state update" ordering issues, which exist with or without Redux, a far easier job.

ng12 8y ago
Agreed. I like to tell people that I like Redux's devtools more than I like Redux. There's a payoff for all the boilerplate.
- bryanrasmussen 8y ago
  if someone doesn't want to they don't need to write most of the Redux boilerplate, my last project a colleague wrote out all the boilerplate you normally see in a reducer - 100s of lines, and then I had to go write a new reducer of the same level of complexity and managed to write it with maybe 20 lines of Object.Assign and some values lookup. For him he found my code harder to reason about because it was not explicit everywhere, but for me his was harder to reason about because I had to read the same thing over and over again with just different names. But I wonder which one devtools would have handled easier, probably his.
- acemarke 8y ago
  Please check out our new `redux-starter-kit` package, which includes utilities to simplify common use cases like store setup, defining reducers, immutable update logic, and even creating entire "slices" of state automatically: https://redux-starter-kit.js.org/ https://redux-starter-kit.js.org/
andy_ppp 8y ago
I don’t agree that state update ordering has ever been an issue, it’s a straw man to justify redux with. The correct solution here is to not design UI updates that can fail because of ordering! Mobx removes all the boilerplate and is far simpler to reason about and test in complex systems. Also async actions/side effects are built in, not third party. If you haven’t tried Mobx it is definitely worth saving yourself thousands of lines of boilerplate in your next project.

4 ms·

On the contrary: Redux's insistence on serializable events and side effect-free reducers makes debugging these pernicious "state update" ordering issues, which

by tomjakubowski 8y ago

ng12 8y ago
Agreed. I like to tell people that I like Redux's devtools more than I like Redux. There's a payoff for all the boilerplate.
- bryanrasmussen 8y ago
  if someone doesn't want to they don't need to write most of the Redux boilerplate, my last project a colleague wrote out all the boilerplate you normally see in a reducer - 100s of lines, and then I had to go write a new reducer of the same level of complexity and managed to write it with maybe 20 lines of Object.Assign and some values lookup. For him he found my code harder to reason about because it was not explicit everywhere, but for me his was harder to reason about because I had to read the same thing over and over again with just different names. But I wonder which one devtools would have handled easier, probably his.
- acemarke 8y ago
  Please check out our new `redux-starter-kit` package, which includes utilities to simplify common use cases like store setup, defining reducers, immutable update logic, and even creating entire "slices" of state automatically: https://redux-starter-kit.js.org/ https://redux-starter-kit.js.org/
andy_ppp 8y ago
I don’t agree that state update ordering has ever been an issue, it’s a straw man to justify redux with. The correct solution here is to not design UI updates that can fail because of ordering! Mobx removes all the boilerplate and is far simpler to reason about and test in complex systems. Also async actions/side effects are built in, not third party. If you haven’t tried Mobx it is definitely worth saving yourself thousands of lines of boilerplate in your next project.