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

71–80 of 133 posts

Re: Redux – Not Dead Yet (2018)

#71

Post by ratww »

thekemkid wrote: post #17
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…

Do you, or anyone else in the team or community, have a good resource you would recommend to people complaining about "too much boilerplate" in redux code? It is likely the most common complaint I see, that I understand to come from a place of people not understanding it this a tool best used for scaling and/or already big projects. Whenever I have worked with Redux in a large project, that "boilerplate" is minimal a…

I don't know if I agree... I've used "traditional" Redux in very large projects and the boilerplate far from minimal, and it grows in the same scale the app grows. And it's in the parts that grow more, which is app code: action types and action creators are very un-DRY and repetitive. Switch statements are way noisier syntatically compared to other solutions such as classes or objects (used in VueX and RTK createSlice). Etc.

I think it speaks volumes when the Redux maintainers are going into a direction that uses less boilerplate, like Redux Toolkit.

Honestly, there's nothing wrong with boilerplate, but I guess it's time to admit that some people love it and others hate it.

Re: Redux – Not Dead Yet (2018)

#72

Post by seeTheAstroturf »

abhisuri97 wrote: post #57

I taught a course on Javascript in undergrad with a unit on react as well as redux (cis.upenn.edu/~cis197, check it out!). To this day, I still think people learning JS should know about redux because of the design pattern it encourages (note that when people are first learning CS, this is probably the first-ish time they're coming across the concept of a reducer and "functional" state that isn't mutated directly). I…

Maybe. I learned redux because I was told to.

The official tutorial was outdated and it set me back weeks because I thought I was wrong.

I suppose the structure was good to learn, my first concept of middleware and reducers.

Re: Redux – Not Dead Yet (2018)

#73

Post by tracker1 »

mharroun wrote: post #68

Redux always had to much boilerplate for me to prefer it. The last couple years I have been using the new Context API and spliting my app state out by creating a global context, and many domain specific contexts where the context contains both the data and functions used to work with that data. Typescript + state with data and functions created a great api per domain. I found this approach just as clean but with less…

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

Re: Redux – Not Dead Yet (2018)

#74

Post by runawaybottle »

acemarke wrote: post #62
izolate wrote: post #48

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.

Not sure what you mean by "moving the goalposts" here. I'm trying to make a few specific points: - Redux is not "dead" in the sense that it is still widely used and is continuing to be adopted - There are definitely many other tools in the React ecosystem that overlap with how you'd use Redux, but the Venn diagrams for the use cases don't entirely match up, and the other solutions don't necessarily have all the capab…

A lot of the pushback is coming from this:

‘ - Redux _has_ been over-used and put in apps where it didn't fit well, and I want people to only use it when it makes sense to do so’. ‘

There are developers working day in and day out in these Redux codebases so our feedback is coming from a real place. There’s a million articles that pushed Redux to the top and got it used in just about everything. Articles just like this one.

This article is literally pushing back against all the reasons why Redux might not be a good fit. There’s very little in it that goes ‘yeah you know what, for this scenario, don’t use Redux’.

Re: Redux – Not Dead Yet (2018)

#75

Post by acemarke »

ratww wrote: post #71
thekemkid wrote: post #17

Earlier quoted context omitted.

Do you, or anyone else in the team or community, have a good resource you would recommend to people complaining about "too much boilerplate" in redux code? It is likely the most common complaint I see, that I understand to come from a place of people not understanding it this a tool best used for scaling and/or already big projects. Whenever I have worked with Redux in a large project, that "boilerplate" is minimal a…

I don't know if I agree... I've used "traditional" Redux in very large projects and the boilerplate far from minimal, and it grows in the same scale the app grows. And it's in the parts that grow more, which is app code: action types and action creators are very un-DRY and repetitive. Switch statements are way noisier syntatically compared to other solutions such as classes or objects (used in VueX and RTK createSlic…

I think it's important to distinguish between the "inherent" complexity" and "incidental" complexity in using Redux [0].

Dispatching actions and writing reducers is _inherent_ complexity. It's part of Redux's design, and is a deliberate level of indirection.

Having to write nested spread operators to perform immutable updates, switch statements in reducers, and `const ADD_TODO = "ADD_TODO"` is _incidental_ complexity. Nothing about Redux's core design _requires_ you to write the code that way. There's valid reasons why those patterns exist [1], but writing a reducer with a switch statement vs a lookup table doesn't change how the Redux data flow behaves.

My goal is to eliminate the incidental complexity, because it's not necessary and does present a barrier to people learning and using Redux.

[0] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...

[1] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

Re: Redux – Not Dead Yet (2018)

#76

Post by tracker1 »

vikingcaffiene wrote: post #52

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-actions-hook

Re: Redux – Not Dead Yet (2018)

#77

Post by acemarke »

tracker1 wrote: post #73
mharroun wrote: post #68

Redux always had to much boilerplate for me to prefer it. The last couple years I have been using the new Context API and spliting my app state out by creating a global context, and many domain specific contexts where the context contains both the data and functions used to work with that data. Typescript + state with data and functions created a great api per domain. I found this approach just as clean but with less…

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...

Re: Redux – Not Dead Yet (2018)

#78

Post by Justsignedup »

So many great things about redux that are hard to mimic...

- the ability to create a middleware that is your analytics listeners. Analytics will listen to actions and spit out analytic info when those actions trigger. Because of this there is literally no analytics code anywhere in your codebase, except encapsulated in that one analytics middleware and sub-tree.

- Ability to just see every state update in dev tools which is AMAZING for tracking down what caused a non-obvious problem. For example: Was it a bad api request? Was it a bug in the reducer? etc. Hard problems suddenly become easier with good debugging tools.

- Ability to persist a part of the store to local storage. This is actually quite nice.

Re: Redux – Not Dead Yet (2018)

#80

Post by acemarke »

runawaybottle wrote: post #74
acemarke wrote: post #62

Earlier quoted context omitted.

Not sure what you mean by "moving the goalposts" here. I'm trying to make a few specific points: - Redux is not "dead" in the sense that it is still widely used and is continuing to be adopted - There are definitely many other tools in the React ecosystem that overlap with how you'd use Redux, but the Venn diagrams for the use cases don't entirely match up, and the other solutions don't necessarily have all the capab…

A lot of the pushback is coming from this: ‘ - Redux _has_ been over-used and put in apps where it didn't fit well, and I want people to only use it when it makes sense to do so’. ‘ There are developers working day in and day out in these Redux codebases so our feedback is coming from a real place. There’s a million articles that pushed Redux to the top and got it used in just about everything. Articles just like thi…

That's because:

- I have no control over the millions of other tutorials that have been written. I can only control my own blog, and the actual Redux docs.

- The question of "When does it make sense to use Redux?" has been answered numerous times already [0] [1] [2]

- I wasn't trying to address the "when?" question in this article. I was trying to answer "is Redux still a viable choice, and how does it compare to other alternatives?"

I've written plenty of 6-10K word blog posts about Redux before that delve into how and when to use it. That wasn't my goal for this post.

[0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

[1] https://redux.js.org/faq/general#when-should-i-use-redux

[2] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

Post reply on HN