Live data from Hacker News

Redux – Not Dead Yet (2018)

blog.isquaredsoftware.com

81–90 of 133 posts

Re: Redux – Not Dead Yet (2018)

#81

Earlier quoted context omitted.

I disagree... I use useSelector, and now all my actions.js files export a default useActions method with a wrapper I wrote... Yeah, the boilerplate setting up the middleware and initial reducer isn't fun... but it's been really rewarding and the react-redux hook has been a godsend. https://www.npmjs.com/package/react-redux-actions-hook

Note that with Redux Toolkit, that store setup is now a single line: const store = configureStore({reducer: rootReducer}) https://redux-toolkit.js.org/usage/usage-guide#simplifying-s...

Cool, but I tend to use sessionStorage as a backup to the store to re-hydrate on reload... I also use the thunks plugin so that I can have actioncreators that do multiple dispatches.

Re: Redux – Not Dead Yet (2018)

#82
post #70

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.

Amazing how many downvotes all the redux critical posts get. Redux is indeed horrible and leads to all sorts of bloat and bugs.

Sunk cost, these people have spent hundreds of hours learning something that ultimately is going to be discarded even more. That's why people are downvoting.

Re: Redux – Not Dead Yet (2018)

#83

Earlier quoted context omitted.

Note that with Redux Toolkit, that store setup is now a single line: const store = configureStore({reducer: rootReducer}) https://redux-toolkit.js.org/usage/usage-guide#simplifying-s...

Cool, but I tend to use sessionStorage as a backup to the store to re-hydrate on reload... I also use the thunks plugin so that I can have actioncreators that do multiple dispatches.

Right, and `configureStore` automatically adds the thunk middleware by default [0], as well as the Redux DevTools extension.

You'd still have to pass in options for whatever persistence addon you want to use, but that would be something like:

    const store = configureStore({
        reducer: rootReducer,
        middleware: [...getDefaultMiddleware(), myPersistenceMiddleware]
    })
Which is still shorter and easier to read than having to mess with `applyMiddleware` and `compose` yourself.

[0] https://redux-toolkit.js.org/api/getDefaultMiddleware#includ...

Re: Redux – Not Dead Yet (2018)

#85
post #70

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.

Amazing how many downvotes all the redux critical posts get. Redux is indeed horrible and leads to all sorts of bloat and bugs.

[deleted]

Re: Redux – Not Dead Yet (2018)

#87

I don’t like the structure Redux forces my apps into. This might be a good opportunity to see what simple solutions people are using to avoid stuff like Redux. I remember reading about this: https://hookstate.js.org/

I am inclined to agree. At first I thought Redux was awesome, but eventually discovered that there is a lot of boilerplate and just a general overhead to doing certain things.

However, I definitely fall into the cluster of people that were "just told to use Redux". For my next React project I will certainly evaluate other approaches.

Re: Redux – Not Dead Yet (2018)

#88
post #70

Earlier quoted context omitted.

Amazing how many downvotes all the redux critical posts get. Redux is indeed horrible and leads to all sorts of bloat and bugs.

Sunk cost, these people have spent hundreds of hours learning something that ultimately is going to be discarded even more. That's why people are downvoting.

No, I downvoted because all the comments amount to X bad Y good. What they are posting has nothing to do with the article. The article even specifically talks about most of the Ys that are getting commented about and address what use-cases they are for that Redux isn't for. It's clear those people are not here to talk about the thing they are commenting on, they are just here to tell everyone they don't like Redux.

Re: Redux – Not Dead Yet (2018)

#89
post #70

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.

Amazing how many downvotes all the redux critical posts get. Redux is indeed horrible and leads to all sorts of bloat and bugs.

They are not critical of Redux in any way more productive than saying X bad Y good. That's why they are getting downvoted.

Re: Redux – Not Dead Yet (2018)

#90

I love Redux but I am very frugal about what I put into the store and have come up with a strong set of design patterns with my team to know what should and should not go there. That, in conjunction with hooks for any other stateful concerns we have, makes for a sane and pleasant dev experience. IMO the biggest and best draw of Redux is how it allows you to completely separate your business logic from your UI layers.…

I do kind of violate this... I tend to use action creators that will accept an event from a component, and use e.target.dataset.someValue as necessary... it's not exactly a violation... but it's muddy... having clean action handler syntax in my Components though it better imho. I use createActionsHook below in every actions.js file... combined with thunks, it's awesome imho. https://www.npmjs.com/package/react-redux-…

Thanks for the perspective. :)

IMO the only downside to your approach is that it couples your action creators to the calling component. That isn't necessarily a bad thing but it all depends on what your particular goals are. If you intend to have your action creators as a kind of "super prop" that is specific to your caller and disposable and single purpose in nature, I think that works. To be successful (again IMHO) you'd want to segregate your business logic outside of that layer into either the reducer (as the redux team recommends) or in a service layer that the actions can talk to (my preferred approach). As always YMMV.

Post reply on HN