4 ms·
>Don't use redux This is a puzzling advice to give to someone who wants to offload business logic away from components, as redux with sagas for example is a gr
by iaml 5y ago
>Don't use redux
This is a puzzling advice to give to someone who wants to offload business logic away from components, as redux with sagas for example is a great place to put it. That way if you use selectors (preferably memoized as well) your components will only update when needed and you can organize business logic however you want.
- hardwaresofton 5y agoIt didn’t seem like the commenter didn’t know what Redux was, but more that they in using it as prescribed they still ran into the same issues. I was suggesting not using/needing redux mostly to reduce the starting level of complexity
- iaml 5y agoI mean gp mentions they don't like the god components, and in my experience the kind of project where this becomes a problem is likely not using redux. Nowadays, redux is pretty well documented and there are ways to reduce boilerplate (for example, redux-toolkit) so I feel like it's a pretty good option to consider.
- deleted 5y ago[deleted]
- hitekker 5y agoA lot of new programmers don’t know the meaning of complexity. They only see the features and not the costs. By the time they finally realize the mess they’ve created, they’ve sunk too much effort and credibility to admit fault.
- hardwaresofton 5y agoYeah I think it's a real shame, most of my zeal these days on the front end is finding the smallest most focused libraries that do certain things -- I always shudder when I see what seems like pattern explosion/new development in libraries like React. Of course, most of this is not React's fault -- they blazed the trail, and it's not like they could have known to build in the semi-automatic reactive system that Vue did right ouf o the gate. That said, KnockoutJS and the whole MVVM revolution along with RXJS were around to learn from.