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

31–40 of 133 posts

Re: Redux – Not Dead Yet (2018)

#31

Post by acemarke »

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…

Yeah, as I talked about in both the original blog post and my parent comment, we've specifically designed Redux Toolkit to eliminate the "incidental complexity" that came along with using Redux [0]:

- Immer makes writing immutable updates easy, because you can write "mutating" logic like `state.todos[5].completed = true`

- `configureStore` sets up a Redux store with good defaults (DevTools extension, thunks, mutation checking) in a single line of code and has easier-to-read options if you do need to tweak the config

- `createSlice` eliminates the need to write any action creators or action types by hand

- Our new `createAsyncThunk` and `createEntityAdapter` APIs (new in v1.3.0 [1]) simplify the common use cases of dispatching actions as part of data fetching and managing normalized data in your state

Also, RTK is written in TypeScript, and designed to infer as much as possible. For example, if you declare the type of the action payload in a `createSlice` reducer, the generated action creator has its payload argument typed automatically to match.

Meanwhile, the React-Redux hooks API generally requires less code than `connect` does, and is easier to use with TypeScript as well.

Finally, we're now encouraging folks to use the "ducks" pattern for single-file Redux logic [2], which cuts down the number of files you might have to work on for a given feature, and using `createSlice` basically gives you ducks files for free [3].

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

[1] https://github.com/reduxjs/redux-toolkit/releases/tag/v1.3.0

[2] https://redux.js.org/style-guide/style-guide#structure-files...

[3] https://redux-toolkit.js.org/usage/usage-guide#exporting-and...

Re: Redux – Not Dead Yet (2018)

#32

Post by eropple »

ccmcarey wrote: post #16
eropple wrote: post #7

Earlier quoted context omitted.

There's stuff like MobX, but much of the point of Redux is the reducer step. You may be happy with just using hooks, though.

Do you mean the point of Redux?

You saw nothing. Nothing!

(Yes, thank you, edited.)

Re: Redux – Not Dead Yet (2018)

#33

Post by sefrost »

petilon wrote: post #25
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…

Overrated. In what kind of application do you need this? In the vast majority of React apps you do not need this.

I found it incredibly useful when debugging race conditions, usually caused by network requests.

Re: Redux – Not Dead Yet (2018)

#34

Post by onion2k »

petilon wrote: post #25
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…

Overrated. In what kind of application do you need this? In the vast majority of React apps you do not need this.

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 don't need to trace actions, but when you do you definitely won't think it's overrated.

Re: Redux – Not Dead Yet (2018)

#35

Post by acemarke »

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…

Yeah, as I tried to make clear in the post, there's many other excellent tools and libraries in the ecosystem, and they _do_ overlap with the kinds of use cases that might have made people pick Redux in the past.

For the record, I've never wanted _everyone_ to use Redux, and I agree with criticisms that Redux has been frequently over-used.

All I want is for folks to look at their use cases, take the time to evaluate tools, and make intelligent decisions about what tools best solve their problems.

Unfortunately, the nature of social media and the development community just doesn't seem to work that way. No one seems to write posts saying "here's a new tool, here's how it compares to existing tools, and here are the tradeoffs involved and the use cases where they might each be relevant". It's always "LOL TOOL X IS DEAD NOW!", even if Tool Y is brand new and has 10 downloads and 2 GH stars while Tool X's daily downloads continue to increase.

Re: Redux – Not Dead Yet (2018)

#37

Post by runawaybottle »

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…

What are the obvious benefits other than fundamentally dumping shared data into a global singleton?

How do you handle testing of connected components? There’s tons of pain points. I’m on a pretty large Redux project too, and every day I wish I could just simplify the whole app (as we scale) by removing Redux.

Re: Redux – Not Dead Yet (2018)

#38

Post by petilon »

onion2k wrote: post #34
petilon wrote: post #25

Earlier quoted context omitted.

Overrated. In what kind of application do you need this? In the vast majority of React apps you do not need this.

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…

> You're right that the majority of React apps don't need to trace actions, but when you do you definitely won't think it's overrated.

I think Redux is overrated because it is used by a lot of applications that don't need it.

Re: Redux – Not Dead Yet (2018)

#39

Post by runawaybottle »

Scarblac wrote: post #28
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 think that complaint usually comes from people who try to put everything related to state in Redux, and not just the parts of it that need to be. Also the 'reducks' pattern of splitting the Redux state into separate files, each containing a reducer and the related actions and selectors helps keep things simple to understand (although I guess it is a bit more overhead, actually).

I’ve read articles about how the Ducks pattern in practice also become untenable.

Re: Redux – Not Dead Yet (2018)

#40

Post by runawaybottle »

onion2k wrote: post #34
petilon wrote: post #25

Earlier quoted context omitted.

Overrated. In what kind of application do you need this? In the vast majority of React apps you do not need this.

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.

Post reply on HN