4 ms·
He starts with a negative tone when describing react & redux without backing up his negatively with proper & convincing arguments just so that later he can thro
by halayli 11y ago
He starts with a negative tone when describing react & redux without backing up his negatively with proper & convincing arguments just so that later he can throw in his alternative solution.
I don't know why we keep doing it but often times we cover our eyes on purpose and brush off existing solutions backed by thousands of engineers so that it's easier to make our points.
- Lazare 11y agoEspecially considering his proposed solutions looks an awfully lot like not-very-fleshed-out remakes of React and Redux.
- jdubray 11y agoThis is not true, please visit the SAM room on Gitter https://gitter.im/jdubray/sam https://gitter.im/jdubray/sam In a nutshell: in redux the reducer updates the model as: state.counter += 1 ; All SAM suggests is that this is an unfortunate coupling, you should write it as: // action function increment(value) { return value + 1 ; } and then present the output of the action to the model: state.counter = data.counter ; Redux does not have any next-action-predicate either.
- halayli 11y agoThat's not true either. In Redux the reducer is always pure and never modifies its arguments, at least in principle. It returns a new copy representing the new state. Dan Ahramov relies on deep-freeze to always assert this fact in all of his tutorials. Regarding next-action, in Redux subscribers are called after the root reducer returns the new state. You can always call dispatch from a subscriber. You and Sam are proving my point by not actually taking the time to understand the existing solutions.
- veenified 11y agoTake a look at this boilerplate project (https://github.com/erikras/react-redux-universal-hot-example https://github.com/erikras/react-redux-universal-hot-example)... I think Redux with the multireducer lib removes that coupling you speak of.
- Lazare 11y agoI'm extremely open to finding a better solution to React/Redux, but your example makes very little sense. > in redux the reducer updates the model as: state.counter += 1 ; That's not how Redux code would look, nor is that how Redux state works. > you should write it as: [...] That actually looks very much like how you'd actually write a reducer. Can you please clarify how you think this differs from idiomatic Redux code? > Redux does not have any next-action-predicate Inventing terms does not aid in advancing a discussion, especially if you do not define them. But reading through the OP, it appears that a next-action-predicate is just a selector, or possibly a selector used to implement what in Redux would be solved my middleware? The description is quite cryptic, but it at least claims to solve a problem which is already solved cleanly in Redux, which rather raises the question of what the advantage it yields is. I mean this nicely, but: You're not really convincing me that SAM is a different pattern. Perhaps a simple example app? Ideally some small idiomatic redux todo app ported to SAM; that should show the differences (and benefits) very clearly.