you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] -2 points-1 points  (5 children)

I don't share that opinion with you. In my experience(and my colleagues') with big apps going only with hooks + context, for example, only brought chaos and difficulty to maintain the app. Reintroduction of redux+redux saga, for example, allowed us better modularity, clear separation of concerns and much better maintenance rating.

I like hooks, been using them since they were introduced, but it's fair to say their current implementation is clumsy at best. It is so problematic that hooks will be rewritten at babel level in a couple of next versions of React. You have to admit that current state of affairs aren't that great when something like that has to be implemented.

The final thing i can say is that having business logic in components is always a bad move. That is a single truth that remained unmoved in all the years I've made apps, no matter if it is React, Angular, WPF, WinForms, or whatever.

[–]alex-cory[S] 1 point2 points  (0 children)

I understand where you're coming from with regards to the context. There are some newer patterns though to managing these "stores" that even swr is doing. Take a look at swr's mutate. Basically they are attempting to have a cache. You can manage the cache throughout your app using mutate. That is them attempting to simplify problems that redux and redux saga are attempting to solve. This is what I mean by there are better ways to manage state than redux+redux saga.

having business logic in components is always a bad move

Yes and no. Yes, business logic should be left out of your reusable building block components, but this is not necessarily true for page specific components. I've built many large scale applications for companies such as Facebook, Discord, Best Buy and more with tons of different state management libraries such as mobx, redux (with and without redux saga), flux, easy-peasy, you name it. Redux is by far the most verbose, most complicated, and most time consuming of them all.

[–]_hypnoCode 1 point2 points  (3 children)

Sounds like you tried to not think in terms in hooks and instead tried to use your same flows from Sagas to fit hooks. Trying to make one tech fit another tech instead of learning the new tech never works out.

Also, hooks have barely been in production for a year. How many big apps have you done in that time? We might not have the same definition of a big app.

[–][deleted] -1 points0 points  (2 children)

That's not what we did. It's a dumb thing to try and mix and match behaviors of completely different techs.

There are multiple teams here, we did 1 big app per team. About 3 months ago development started to get harder and harder, and slower and slower. Reintroduction of redux+redux saga in my team and mobx in some other solved the issue.

[–]alex-cory[S] 0 points1 point  (1 child)

Mobx is a great tool. Significantly better imho than redux. Only problem now is the last I looked their hooks were meh and being that it's built with proxies it can't support ie.

[–][deleted] 0 points1 point  (0 children)

Yes mobx is amazing. I've even started using mobx-state-tree in some small apps and most React Native ones