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

Redesigning Redux

medium.com

Post reply on HN
Print view View original

81–88 of 88 posts

Re: Redesigning Redux

#81

Post by eropple »

pault wrote: post #79
eropple wrote: post #75

Earlier quoted context omitted.

> Why would you serialize a pending network request? I wouldn't. That's why I wouldn't put anything related to it in my Redux state! But, like, I'm willing to be convinced. This is just where I'm at right now. Maybe your method would make more sense than redux-thunk does to me; have you written anything in more detail about this? (I'm not scared of middlewares, I've used Redux and middlewares even in non-web contexts…

I agree, I'm pretty strict about keeping UI state out of the store, but when you need to coordinate a bunch of components based on the status of network API requests and you already have a global message bus available... I've created a gist[1] with some snippets from a current project; it's still alpha, but you can get a general feeling for how the data flow works. I would clean it up a bit if I were officially relea…

I'll look at this tomorrow. Thank you!

When I refer to serializing an action, I mean that, by necessity, the current state of any in-flight asynchronous actions must be recorded and saved--or else I don't think serialization works, its promises fail and you end up with a state whose completeness you can't guarantee. That opinion may change when I look at this tomorrow, of course--you very well may be cleverer than I am!

I use redux-storage for what you describe for persistence, btw. I like it a lot, I can easily select what I'm going to persist, and I don't have to maintain it. I dynamically pick a backend: IndexedDB where supported, LocalStorage where not.

Re: Redesigning Redux

#82

Post by mezzode »

bpicolo wrote: post #36
zzzzzzzza wrote: post #33

Earlier quoted context omitted.

I missed the part where you explained why changing the reducer to an object with methods would bring any benefits, or what's bad about message passing (it seems to me off the top of my head that changing this would at the very least, break redux observable as it currently works)

> to an object with methods would bring any benefits It lets static typing do a lot more work for you when using Typescript/Flow. Less to remember and less to break. Message passing is a really useful architectural choice because it lets you do powerful global operations. It's a lot crummier on the development ergonomics front.

You can already write interfaces for your Redux actions in TypeScript to get the benefits of static typing, so I'm not even sure that there would be an appreciable improvement if Redux used methods instead.

Re: Redesigning Redux

#83

Post by kn8 »

woah wrote: post #56

While Redux is great because it enforces a single source of truth, the whole thing with "actions" and "reducers" in Redux is a huge source of boilerplate. In almost every Redux project I have worked on, developers bring in some weird scheme to reduce the boilerplate load of having to come up with a bunch of events when all that anyone wants to do is call some functions. The fact that Redux forces you to use events to…

I share this sentiment. I always felt like Redux had the right idea (single store modified via actions), but the API was just making things unnecessarily complicated causing people to either write lots of boilerplate or come up with complicated workarounds.

Here's yet another similar approach, also in 100 LOC https://qubitproducts.github.io/tiny-atom/. Been using it for a year in a few projects.

Re: Redesigning Redux

#84

Post by worg »

Waterluvian wrote: post #48
agentultra wrote: post #32

Earlier quoted context omitted.

A functional programming rosetta stone? Sounds challenging and interesting!

Hah. I just meant maybe a blog post that maps the terms I use in JavaScript land with math land. Ie. "it's not a reducer it's a functormonadicfoobar"

https://eloquentjavascript.net/3rd_edition/00_intro.html

Not exactly a blogpost but a nice reading, explains a lot of the functional programming terms and their mathematical analogs.

edit: s/slang/terms

Re: Redesigning Redux

#85

Post by adamsea »

pault wrote: post #64
adamsea wrote: post #54

Earlier quoted context omitted.

One approach is to write a reducer which has `isWaiting`, `error`, `finished` bools (in addition to whatever data said promise eventually modifies), or something similar, and programmatically update them in your actions/thunks. This effectively tracks the state of the promise (resolved/not resolved, error).I think the Flux "standard action" puts something similar in the action object - not sure what they do with it t…

I always put a `pending` property on the `meta` object, and any component that needs to show network status can just check that property on every render cycle. Aside from requiring some extra utility functions in the reducers to prevent having to updating `pending` for every state of the request it's rock solid and I haven't ever encountered a situation where it wouldn't work. You can get a _lot_ of mileage out of co…

Agreed. And that sounds like a great approach. We didn’t conform exactly to FSA (which I want to try out on future projects). Our isWaiting was equivalent to your pending, I think.

(Edit) FYI we had actions to set isWaiting, etc.

Re: Redesigning Redux

#86

Post by adamsea »

eropple wrote: post #75
pault wrote: post #74

Earlier quoted context omitted.

Why would you serialize a pending network request? I use a property whitelist in my serializer that drops any application state not related to the business logic. Also, I don't use redux-thunk, I move all async operations to middleware and action creators are synchronous and declarative. For example, an API request will be defined in an action creator as an endpoint, http method, and request body, and the middleware…

> Why would you serialize a pending network request? I wouldn't. That's why I wouldn't put anything related to it in my Redux state! But, like, I'm willing to be convinced. This is just where I'm at right now. Maybe your method would make more sense than redux-thunk does to me; have you written anything in more detail about this? (I'm not scared of middlewares, I've used Redux and middlewares even in non-web contexts…

FYI we used redux thunk

Re: Redesigning Redux

#87

Post by adamsea »

adamsea wrote: post #85
pault wrote: post #64

Earlier quoted context omitted.

I always put a `pending` property on the `meta` object, and any component that needs to show network status can just check that property on every render cycle. Aside from requiring some extra utility functions in the reducers to prevent having to updating `pending` for every state of the request it's rock solid and I haven't ever encountered a situation where it wouldn't work. You can get a _lot_ of mileage out of co…

Agreed. And that sounds like a great approach. We didn’t conform exactly to FSA (which I want to try out on future projects). Our isWaiting was equivalent to your pending, I think. (Edit) FYI we had actions to set isWaiting, etc.

Also, this conversation got me thinking about the difference between application state, state of an asynchronous request, and Redux actions as events (I'm thinking of the request/response events in node.js), and using them as such - to pass data throughout the application (in addition to the payload). Which I guess is what FSA is all about? So, thank you!

Re: Redesigning Redux

#88

Post by adamsea »

pault wrote: post #79
eropple wrote: post #75

Earlier quoted context omitted.

> Why would you serialize a pending network request? I wouldn't. That's why I wouldn't put anything related to it in my Redux state! But, like, I'm willing to be convinced. This is just where I'm at right now. Maybe your method would make more sense than redux-thunk does to me; have you written anything in more detail about this? (I'm not scared of middlewares, I've used Redux and middlewares even in non-web contexts…

I agree, I'm pretty strict about keeping UI state out of the store, but when you need to coordinate a bunch of components based on the status of network API requests and you already have a global message bus available... I've created a gist[1] with some snippets from a current project; it's still alpha, but you can get a general feeling for how the data flow works. I would clean it up a bit if I were officially relea…

This is very cool! Thank you for sharing this. We have had a somewhat similar approach, but stored request/response success/error states in request-specific reducers (it may have been better to put that data in the actions).

I think you will find of interest how we've used Immutable.js Maps for reducer state and Immutable.js Records as an easy way to create and pass around (guaranteed immutable) action types.

We were using Immutable.js and functional-style JS a lot in general, so it was a good fit.

https://gist.github.com/adamcee/3191762f2af43ec62a4b335b6695...

Post reply on HN