Live data from Hacker News

Redux – Not Dead Yet (2018)

blog.isquaredsoftware.com

91–100 of 133 posts

Re: Redux – Not Dead Yet (2018)

#91

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 think more than anything its important to consider your store in the same manner you would a database

Yes and to keep it normalized. IMO, Redux is incomplete without some sort of selector layer, which acts as the metaphorical database views.

https://github.com/reduxjs/reselect

Re: Redux – Not Dead Yet (2018)

#92
post #45

Earlier quoted context omitted.

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.

Note that the new `createAsyncThunk` API in Redux Toolkit handles generating and dispatching the promise lifecycle actions for you [0]. Also, while sagas are a great power tool, most Redux apps don't need them [1]. [0] https://redux-toolkit.js.org/api/createAsyncThunk [1] https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh...

Awesome! It's great to finally have some links to share.

The company I'm currently working with is the first time I've used sagas / observables / "anything async is through side effects". I've constantly been saying "this is madness, this giant block of code, all these concepts, all this room for things to go wrong, just to do a `fetch`?". It's also the first time in a few years of using redux I've had to deal with race conditions.

Edit: Oh, and you can even `await dispatch`! All the things I've been doing in Redux for years and told I shouldn't, now being officially endorsed.

Re: Redux – Not Dead Yet (2018)

#93

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 w…

One thing I like is that it's really easy to put a client library (for, say, some REST service) behind a combine-reducerable Redux store and a few exposed "action creators" (event emitters). Especially if you're using TypeScript so all that stuff's easy to find and understand. Anyone familiar with Redux will be able to use it immediately, and it'll work just fine anywhere JavaScript does (provided whatever other packages the client lib depends on will work on a given platform) including places you might want, for good reasons, to use JavaScript but lean on some UI system other than React (Apple TV, say, or maybe Electron).

Re: Redux – Not Dead Yet (2018)

#94
post #88

Earlier quoted context omitted.

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.

I have yet to be given a good usecase for Redux. All I see is code that ends up causing issues:

- redux pollution (not cleaning up state and things leaking)

- because you can't access redux state directly, components have to copy redux state and store them as props (which makes 0 sense, its state not props). But now you run into the issue where the local prop is not in sync with redux since redux updates are correctly done in chunks.

Re: Redux – Not Dead Yet (2018)

#95
post #65
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…

I was about to ask what kind of stakeholder gives a damn about sitting down with you and going through an action trace to see why a certain screen rendered, but I’m glad you added the note at the bottom. Regardless, yourself or another developer as the “stakeholder” in this scenario is a bit of a cop out. In the real world stakeholders aren’t technically inclined and even if they are they don’t care about this minuti…

I was tempted to say something like ‘are you recently out of college or a bootcamp? What stakeholder are you impressing here with a Redux stack trace?’.

I tried to avoid it but your post just brought out it of me.

Re: Redux – Not Dead Yet (2018)

#97

Earlier quoted context omitted.

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)…

Oh, the results are handled by the reducer... it's not that far off.. expecting an event with a given shape, as opposed to a direct argument. Can even be split, one for the view specifically another for the more pure actioncreator... with the thunks+async function, it's easy to have a start, await api call and finish/error events dispatched.

Re: Redux – Not Dead Yet (2018)

#98

Earlier quoted context omitted.

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)…

Oh, the results are handled by the reducer... it's not that far off.. expecting an event with a given shape, as opposed to a direct argument. Can even be split, one for the view specifically another for the more pure actioncreator... with the thunks+async function, it's easy to have a start, await api call and finish/error events dispatched.

Yep! :) Sounds like you've thought it through and I see your point.

Re: Redux – Not Dead Yet (2018)

#99

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

That would be the "Style Guide" docs page: https://redux.js.org/style-guide/style-guide

Thank you kind stranger :)

Re: Redux – Not Dead Yet (2018)

#100
post #91

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 think more than anything its important to consider your store in the same manner you would a database Yes and to keep it normalized. IMO, Redux is incomplete without some sort of selector layer, which acts as the metaphorical database views. https://github.com/reduxjs/reselect

We've recommended normalizing data as a pattern for years [0], but never had any official tooling to support that use case. Redux Toolkit 1.3 now has a new `createEntityAdapter` API that can help with the process of inserting and updating normalized data [1].

[0] https://redux.js.org/recipes/structuring-reducers/normalizin...

[1] https://redux-toolkit.js.org/api/createEntityAdapter

Post reply on HN