It's funny because scrolling in this article is a stuttery mess (Firefox on Linux).
Progressive React
81–88 of 88 posts
Re: Progressive React
#82Earlier quoted context omitted.
> "set data" style reducers I've heard this before but don't really understand it. Most of my reducers are storing and maybe updating data loaded from the server. What's wrong with this pattern?
Our new "Style Guide" docs page gives a recommendation to "model actions as 'events', not 'setters' [0], and there were two recent talks on this topic that go into a lot more detail [1] [2]. [0] https://redux.js.org/style-guide/style-guide/#model-actions-... [1] https://github.com/dmmulroy/talks/blob/master/event-driven-r... [2] https://youtu.be/K6OlKeQRCzo?t=2626 / https://rangle.slides.com/yazanalaboudi/deck#/
I don't think actions are what they're talking about, but reducers as setters vs reducers with more complex logic. I stumbled against the same thing last week, and rather than duplicating the logic in two reducers I settled on putting the logic in the action and turning both reducers into simple setters.
Re: Progressive React
#83Earlier quoted context omitted.
Our new "Style Guide" docs page gives a recommendation to "model actions as 'events', not 'setters' [0], and there were two recent talks on this topic that go into a lot more detail [1] [2]. [0] https://redux.js.org/style-guide/style-guide/#model-actions-... [1] https://github.com/dmmulroy/talks/blob/master/event-driven-r... [2] https://youtu.be/K6OlKeQRCzo?t=2626 / https://rangle.slides.com/yazanalaboudi/deck#/
> "model actions as 'events', not 'setters' I don't think actions are what they're talking about, but reducers as setters vs reducers with more complex logic. I stumbled against the same thing last week, and rather than duplicating the logic in two reducers I settled on putting the logic in the action and turning both reducers into simple setters.
When you mentally model an action as a "setter", like `SET_PIZZAS_ORDERED`, the reducer usually has almost no logic and just blindly accepts whatever value was in the action. The work of calculating the value was done before the action was dispatched.
If you model actions conceptually as "events", the corollary is that the work of calculating the new state typically ends up in the reducer.
Re: Progressive React
#84Earlier quoted context omitted.
Only problem with Redux is it can be misused quite easily. The codebase at work has performance issues because of Redux, rerender issues because of reselect (not confirmed yet) and imo very very hard to read code because of Redux-Thunk. The state management was implemented by one person and everyone else is terrified of touching that part of the codebase. Im not blaming redux for this, this is clearly a problem with…
Hi, I'm a Redux maintainer. If you've got any specific concerns I can help with, I'd be happy to try to offer advice. Out of curiosity, what issues have you been seeing with using thunks? I'd specifically encourage you to check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creatin…
Issues with thunks are maybe(?) due to our implementation again, but we have way too many dispatches being called (100s of lines of dispatch calls for one action sometimes). It becomes quite hard to trace what happens when a certain business logic is executed because of this.
For example, say we have an action to delete a domain level entity, lets say this is a book, well books can have paragraphs, paragraphs can have sentences and sentences can have words (normalized state, terrible example I know, but all I could think of atm). Well the action to delete a book, has dispatches to delete all children entities as well. These dispatches actually may have other dispatches as well for ui stuff etc. Doing redux this way really didn't scale well for us, but I suppose we have very very unique, complex business logic compared to other projects.
The style guide looks excellent, I think this would have made the codebase easier to follow. I will defs be following this for my personal projects.
Thanks
Re: Progressive React
#85Earlier quoted context omitted.
> "model actions as 'events', not 'setters' I don't think actions are what they're talking about, but reducers as setters vs reducers with more complex logic. I stumbled against the same thing last week, and rather than duplicating the logic in two reducers I settled on putting the logic in the action and turning both reducers into simple setters.
That's actually kind of the point. When you mentally model an action as a "setter", like `SET_PIZZAS_ORDERED`, the reducer usually has almost no logic and just blindly accepts whatever value was in the action. The work of calculating the value was done before the action was dispatched. If you model actions conceptually as "events", the corollary is that the work of calculating the new state typically ends up in the r…
Re: Progressive React
#86Earlier quoted context omitted.
Hi, I'm a Redux maintainer. If you've got any specific concerns I can help with, I'd be happy to try to offer advice. Out of curiosity, what issues have you been seeing with using thunks? I'd specifically encourage you to check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creatin…
Hey thanks for reaching out, that's very nice of you :), I have no specific concerns atm but will reach out I do need help. Issues with thunks are maybe(?) due to our implementation again, but we have way too many dispatches being called (100s of lines of dispatch calls for one action sometimes). It becomes quite hard to trace what happens when a certain business logic is executed because of this. For example, say we…
https://news.ycombinator.com/item?id=21853160
Also, note that our new Redux Toolkit package will at least help simplify your existing logic, and you can begin migrating to it incrementally:
Re: Progressive React
#87Earlier quoted context omitted.
Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering. Jokes aside, everything has its place. You're still allowed to hate it though. For example, I hate Redux because everyone uses it for every React app and it's got boilerplate up the wazoo. Just know that if you "hate" things, though, you won't learn as much in life, like I won't learn how to use time travel debugging…
I’m not sure this is true. For example, what can I learn from JS that isn’t in better languages? In tech we have this weird situation where many things become popular without good reason. It’s ironic, because a group of people (nerds) who think they are the epitome of rationality are actually the opposite: we make very emotional decisions when we could be entirely rational, as we have access to data other fields do n…
I only said "at least a few core ideas" -- not, "at least a few unique core ideas". Sure there are other places you can learn the same things, which of course doesn't mean that JS is now somehow stripped of that value.