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

JavaScript Power Tools: Real-World Redux-Saga Patterns

formidable.com

Post reply on HN
Print view View original

41–47 of 47 posts

Re: JavaScript Power Tools: Real-World Redux-Saga Patterns

#41

Post by hakanito »

mhink wrote: post #37
inglor wrote: post #35

A whole class of problems you wouldn't have in the first place with MobX. So much code in the article for doing so little - where good design could solve the issues much more elegantly using plain function composition and JS concepts.

Author here. As I mentioned in other posts, I don't believe redux-saga is the be-all-end-all solution to every problem in client-side Javascript. It's a good solution for codebases which need to coordinate among several different asynchronous processes. And for what it's worth, I wanted to err on the side of verbosity. I find that a lot of blog posts kinda elide over too much, and so I was actively trying to break do…

I think it would be great for the community to see a writeup on how complex async flows can be handled with MobX reactions and data atoms, two pretty powerful concepts IMO

Re: JavaScript Power Tools: Real-World Redux-Saga Patterns

#42

Post by BigJono »

acemarke wrote: post #39
BigJono wrote: post #38

Earlier quoted context omitted.

> Because of that, async behavior and side effects are handled via middleware. It shouldn't be though. The middleware pattern makes a lot of sense for transforming data (communication between mismatched APIs etc), or using it in some way before passing it on (logging, analytics etc). IMO it's totally wrong for this use case though. All redux-thunk is doing is taking some "action", clobbering it, pretending it doesn't…

Yes, yes, we've had this argument about redux-thunk in prior threads :) That said, it's worth noting that the explicit design goal for middleware _was_ for async behavior, per the comments from Dan and Andrew I've quoted in http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... . To pick out one specific quote from Andrew: > [the] reason the middleware API exists in the first place is because we explicitly d…

Yeah I'm under no illusions that me and Dan Abramov are operating under a vastly different model for how we think an application should be structured. The concept of a data store having a "solution for async" is, to me at least, absurd. It's like asking why my fridge doesn't have a solution for next day grocery delivery.

I don't see why my fridge needs to be concerned about whether my broccoli is sitting on the bench ready to be put in, or still being washed down at the green grocers.

From the fridge's point of view, a piece of broccoli is inserted into it at a specific point of time. The contents of the fridge can be defined as an ordered set of insertions and removals. The fridge's state depends on knowing whether a piece of broccoli was inserted at 12:58pm or 1:03pm, since that may change the order things were stacked in, but it doesn't need to know whether I placed an order for that broccoli this morning, yesterday, or a week ago; or how it arrived at my house. Making my fridge responsible for that process would seem to violate the concept of separation of concerns.

Re: JavaScript Power Tools: Real-World Redux-Saga Patterns

#43

Post by k__ »

BigJono wrote: post #42
acemarke wrote: post #39

Earlier quoted context omitted.

Yes, yes, we've had this argument about redux-thunk in prior threads :) That said, it's worth noting that the explicit design goal for middleware _was_ for async behavior, per the comments from Dan and Andrew I've quoted in http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... . To pick out one specific quote from Andrew: > [the] reason the middleware API exists in the first place is because we explicitly d…

Yeah I'm under no illusions that me and Dan Abramov are operating under a vastly different model for how we think an application should be structured. The concept of a data store having a "solution for async" is, to me at least, absurd. It's like asking why my fridge doesn't have a solution for next day grocery delivery. I don't see why my fridge needs to be concerned about whether my broccoli is sitting on the bench…

Finally someone sane, thanks.

Funny thing is that Dan himself said Redux could be implemented in 5 lines of RxJS and was also rathere interested in observables til he met some haters on a conf.

I remember him asking a question about observables being the next thing or future or something and the speaker just didn't know what to say.

Re: JavaScript Power Tools: Real-World Redux-Saga Patterns

#45

Post by kuon »

eric_b wrote: post #22

I worked on a fairly large and high traffic React app. It had some complicated async flows, so the team moved from redux-thunk to sagas. The claims that testability is improved do not ring true to me. Some of those tests were just awful to write and maintain. I'm sure someone will say "you were doing it wrong" but there were many folks on the team following advice from the maintainers themselves on Discord. General u…

We have been trying elm, and while it has still poor support for "web API", maintaining and growing an elm app has been the most pleasurable and easy thing that happened to us in a long time.

Re: JavaScript Power Tools: Real-World Redux-Saga Patterns

#46

Post by _pmf_ »

eric_b wrote: post #22

I worked on a fairly large and high traffic React app. It had some complicated async flows, so the team moved from redux-thunk to sagas. The claims that testability is improved do not ring true to me. Some of those tests were just awful to write and maintain. I'm sure someone will say "you were doing it wrong" but there were many folks on the team following advice from the maintainers themselves on Discord. General u…

> After the codebase was converted, the team generally concurred that sagas were a waste of time and effort, especially with async/await gaining steam.

Aren't sagas and async/await completely orthogonal issues or am I missing something?

Re: JavaScript Power Tools: Real-World Redux-Saga Patterns

#47

Post by shados »

k__ wrote: post #29
tarr11 wrote: post #21

Earlier quoted context omitted.

I find observables, rxjs and redux-observable code to be hard to read and step through debug. Redux saga is very easy to read, works well with the chrome debugger, and plugs into a wide variety of use cases pretty seamlessly.

Ah, no I didn't mean using Redux with observables instead of Redux-Saga, but to drop Redux entirely and use observables.

I've been fascinated by approaches like the following: https://michalzalecki.com/use-rxjs-with-react/

Building on top of those ideas I built something a bit more powerful and feature complete than the example in that blog post, but the exact implementation doesn't matter: having RxJS driving the show is really, really cool.

Async issues? What async issues?

Post reply on HN