Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redux – Not Dead Yet (2018)

blog.isquaredsoftware.com

Post reply on HN
Print view View original

41–50 of 133 posts

Re: Redux – Not Dead Yet (2018)

#41

Post by adz_6891 »

Ozzie_osman wrote: post #11
acemarke wrote: post #2

Oh hey, that's my post. I first wrote it back in 2018, and just updated it yesterday with some additional links and comparisons. (Actually was considering retitling it after getting some feedback last night, but given that the link just got submitted here, I'll leave it as-is for now.) A few quick notes: - If you haven't looked at Redux in a while, please try out our official Redux Toolkit package [0], which is now o…

That was a great article—wish I had read it back in 2018! I'll chime in with some thoughts, as someone who has built several apps using React/Redux. What's happened with me (and others I've seen) has been discovering Redux, falling in love, and thinking "I'll use it for everything!" There's something about the simplicity of having a single state tree, that is immutable and debuggable that just blows your mind. Then y…

Thanks for sharing this, is interesting to hear what other folks are doing in practice!

We were actually thinking of migrating to something similar in terms of data fetching to Apollo/graphql and leaving redux for more app wide state problems.

Could you share any further insights on how you started organising this project? I.e. some pieces in Apollo/graphQL while maintaining a redux core, (presumably that's the core you started with?). Would be really interested.

Also I share your sentiment exactly, redux isn't dead. It's still a really solid approach to state management, and in complex applications I still think it's one of the best options. Thanks and kudos to the maintainers!

Re: Redux – Not Dead Yet (2018)

#42

Post by sergiotapia »

The most overrated tool I've ever had to misfortune of having to wrangle. Talk about bloat and lasagna code.

I've used mobx and it's better. Now I use apollo, and it's even better.

Just thinking about having to use redux and sagas and all that bloat makes my stress levels rise. I can't believe it became as big as it did.

"muh time travel" is a meme of epic proportions.

Re: Redux – Not Dead Yet (2018)

#43

Post by sergiotapia »

warp wrote: post #3

I've recently tried using Redux for a side-project. While it solves the problem (organizing state), I feel there is too much boilerplate for my small project. Are there any popular alternatives which don't use reducers? EDIT: thanks for all the responses, I'll check them out :)

Use mobx! It's 5% of the code you would have to write using redux and their gigantic box of tools.

Re: Redux – Not Dead Yet (2018)

#44

Post by stillbourne »

imbusy111 wrote: post #15
stillbourne wrote: post #5

I really think it should die, from a DDD perspective EDA should be handled as backend tasks with CQRS. If your api server isn't handling that then you really should stand up a BFF. I get that Redux is designed to handle all of that on the front end but it just doesn't belong there. I have seen too many projects devolve into garbage because they are trying to shoehorn too much crap into reducer patterns when it just d…

How do you update the front-end state after the backend task is complete other than reload the whole page?

websockets or any stream service such as kafka

Re: Redux – Not Dead Yet (2018)

#45

Post by jfengel »

runawaybottle wrote: post #40
onion2k wrote: post #34

Earlier quoted context omitted.

In the vast majority of React apps you do not need this. I work on an app that has a total of about 400 separate Redux actions across half a dozen reducers and a couple of stores. There's a lot of things that cause side effects. Being about to see what actions fired with various props is immensely useful for debugging. redux-devtools and Reactotron are immensely useful. You're right that the majority of React apps do…

Can you give me an example how you got to 400 actions? Just enumerate like 5 or so, I’m assuming you are building features where groups of actions are just necessary based on the patterns you are using. I’m genuinely curious because I feel like this kind of inflation of actions/reducers in Redux is what makes it nightmarish.

For one thing they do encourage a lot of tiny actions. A frequent pattern I use requires three actions for every server call: one to trigger a saga, one when it succeeds, and one for when it fails.

The standard form is incredibly verbose, I've started to shift away from it.

Re: Redux – Not Dead Yet (2018)

#46

Post by dointheatl »

warp wrote: post #3

I've recently tried using Redux for a side-project. While it solves the problem (organizing state), I feel there is too much boilerplate for my small project. Are there any popular alternatives which don't use reducers? EDIT: thanks for all the responses, I'll check them out :)

I've recently had success using https://github.com/rematch/rematch for a small project. Significantly less boilerplate, though admittedly the documentation is a bit sparse.

Re: Redux – Not Dead Yet (2018)

#47

Post by reflectiv »

sergiotapia wrote: post #43
warp wrote: post #3

I've recently tried using Redux for a side-project. While it solves the problem (organizing state), I feel there is too much boilerplate for my small project. Are there any popular alternatives which don't use reducers? EDIT: thanks for all the responses, I'll check them out :)

Use mobx! It's 5% of the code you would have to write using redux and their gigantic box of tools.

Also check out mobx-state-tree...made by the same people and more suited towards large applications.

I personally love mobx-state-tree (and mobx!). I really wish more would not jump straight for redux/etc without giving the powerful abstraction of observables via mobx a shot.

Re: Redux – Not Dead Yet (2018)

#48

Post by izolate »

I don't like how this article moves the goal posts of whether redux fits our use case or not. It has some valid arguments (dev tools) but the overhead of the boilerplate and tooling around redux is just not worth it IMO.

Much better to break your app state into various custom hooks that leverage Context API and the `useReducer` hook.

Re: Redux – Not Dead Yet (2018)

#49

Post by onion2k »

runawaybottle wrote: post #40
onion2k wrote: post #34

Earlier quoted context omitted.

In the vast majority of React apps you do not need this. I work on an app that has a total of about 400 separate Redux actions across half a dozen reducers and a couple of stores. There's a lot of things that cause side effects. Being about to see what actions fired with various props is immensely useful for debugging. redux-devtools and Reactotron are immensely useful. You're right that the majority of React apps do…

Can you give me an example how you got to 400 actions? Just enumerate like 5 or so, I’m assuming you are building features where groups of actions are just necessary based on the patterns you are using. I’m genuinely curious because I feel like this kind of inflation of actions/reducers in Redux is what makes it nightmarish.

Can you give me an example how you got to 400 actions?

I'm not going to go in to detail on HN, but the app I work on is used to make diagrams for the legal industry and to define how they change over time. It's sort of like Visio for lawyers, with a basic animation editor that understands the underlying data. There are a lot of actions simply because it does a lot of things that can't be generalised in to higher level actions (well, they could, but it'd be messy.)

Re: Redux – Not Dead Yet (2018)

#50

Post by antew »

acemarke wrote: post #22
sktrdie wrote: post #20

One underrated thing that I miss from using Redux is the "action trace". You can literally sit down with the stakeholders [1] and explain the exact things that caused a screen to render . And these things are not cryptic function calls with stack-traces, but simple and chronologically ordered sets of human readable "actions" (I like to think of them as events) like UserFetched -> PlanFetched ( ) -> FrozenUser. One ca…

It's worth noting that the Redux DevTools Extension _can_ capture and display a literal stack trace for every dispatched action, if you've enabled that while setting up your store. This allows you to see what part of your app triggered each state update: https://github.com/zalmoxisus/redux-devtools-extension/blob/...

I always see you in these Redux threads and you are always so helpful, thank you!
Post reply on HN