4 ms·

Redux-sagas[0] makes great use of generators. I found it a fantastic tool, if you're already in the redux ecosystem, and have an application that sprawls enough

Redux-sagas[0] makes great use of generators. I found it a fantastic tool, if you're already in the redux ecosystem, and have an application that sprawls enough to benefit. It's great when you have to manage multiple process lifecycles. A single "saga" can summaries an entire service lifespan in just a few lines of code. Good candidates include a socket connection, a user session, analytics etc. I desperately want to use it with my current project (streaming video) but our code's too mature to introduce such an architectural change. The downsides are: - a quirky syntax that needs learning, and is of the "loose with semantics" style - like Rails-eque REST's play with HTTP methods - it's hard to test (despite what the documentation claims). It's highly declarative, and such code seems hard to test. [0] http://redux-saga.js.org/ http://redux-saga.js.org/

cageface 4y ago
I had to rescue a saga based project that went badly off the rails and it was some of the hardest code I’ve ever had to debug in any language. Code flow was very difficult to reason about and forget about trying to use stack traces.
- tylerchurch 4y ago
  Yeah I had to rescue a buggy React Native app where the devs put every backend call into sagas. It was a pain to debug and I’ve since almost entirely ripped sagas out. It’ll be a good day when I can delete it as a dependency.
pgorczak 4y ago
Async generators similarly open up different ways to program complex / multi step user interactions. Instead of creating “state machine” objects that mutate on every input, you can have async functions aka coroutines that iterate over user inputs, making the flow of an interaction much more explicit.
isakkeyten 4y ago
Be careful. You will summon acemarke with this comment.
- acemarke 4y ago
  HAH! and ironically I read this literally 10 minutes after you posted it :) dons maintainer hat <ObligatoryResponse> We've been generally recommending against use of sagas for years - they're a power tool, and very few apps need that. They're also a bad fit for basic data fetching. Today, Redux Toolkit's "RTK Query" API solves the data fetching and caching use case, and the RTK "listener" middleware solves the reactive logic use case with a simpler API, smaller bundle size, and better TS support. Resources: - https://redux.js.org/tutorials/essentials/part-7-rtk-query-basics https://redux.js.org/tutorials/essentials/part-7-rtk-query-b... - https://redux-toolkit.js.org/rtk-query/overview https://redux-toolkit.js.org/rtk-query/overview - https://redux-toolkit.js.org/api/createListenerMiddleware https://redux-toolkit.js.org/api/createListenerMiddleware - https://blog.isquaredsoftware.com/2022/06/presentations-modern-redux-rtk/ https://blog.isquaredsoftware.com/2022/06/presentations-mode... </ObligatoryResponse>
  - whilenot-dev 4y ago
    I'll use your nice response for an actual question/remark, gotcha! =) Recently I had a look at the kubeshop-dashboard repo[1] and their use of the RTK Query API[2]. When I write the boilerplate for any SPA nowadays, I usually like to merge any fetching logic with the lib-specific notification/toast-methods, in order to render something to the user about any reached warning- or error-timeouts for each ongoing fetch by default. Meaning: - every new fetch would start a timer - after 10secs a warning-notification is shown "a fetch takes longer than expected..." - and after 30secs the AbortController signals the cancelling of the ongoing fetch and an error-notification is shown "fetch took to long. click to try again." The implementation of react-query, its "hook-yfied" nature, makes it super easy to wrap it and merge it with the component-lib to create such a thing. I just need to wrap its provided hooks (useQuery, useMutation) with "hook-creators" (I usually call them createQueryHook and createMutationHook) and don't need to dive into any of its implementation specific details. But createApi, as provided by RTK Query API, makes this quite a bit harder, or so it seems to me at least. How would you wrap createApi to provide such a functionality for every fetch by default? [1]: https://github.com/kubeshop/testkube-dashboard https://github.com/kubeshop/testkube-dashboard [2]: https://github.com/kubeshop/testkube-dashboard/tree/main/src/services https://github.com/kubeshop/testkube-dashboard/tree/main/src...
qudat 4y ago
> it's hard to test (despite what the documentation claims). It's highly declarative, and such code seems hard to test. redux-saga member here. If we concede that mocks are inherently difficult to get right and maintain, often requiring libraries or testing frameworks to do a lot of the heavy lifting, then I would argue testing sagas is a breeze in comparison. The real magic behind redux-saga and its use of generators is the end-user functions do not have side-effects at all, they merely describe what those side-effects ought to look like. The library activates the side-effects in its runtime, the end-user just yields to json objects. So in order to test sagas, all you need is to run the generator and make sure it yields the things you expect it to yield. https://bower.sh/simplify-testing-async-io-javascript https://bower.sh/simplify-testing-async-io-javascript Having said all that, because the react world has heavily shifted towards hooks -- which explicitly make the view layer impure and hard to unit test -- a bunch of tooling has come out to prefer integration testing. In particular, testing user flows and evaluating what the user sees. In this paradigm, testing individual sagas or even react components is not nearly as valuable.
- sktrdie 4y ago
  First of all, sagas are an amazing concept that I still cherish even if I don’t use them anymore (hype not there?). Regarding the hooks comment I’m not sure I follow. Surely components are also idempotent (if you skip useEffect) and should be replayable - that’s at least how I think react refresh can manage to keep state intact during file changes in development. Anyway I still very much value the concepts behind sagas so thanks for great work.
  - qudat 4y ago
    > Regarding the hooks comment I’m not sure I follow. Surely components are also idempotent (if you skip useEffect) and should be replayable - that’s at least how I think react refresh can manage to keep state intact during file changes in development. We used to have the concept of smart and dumb components, with dumb components we could test if we provide X props we could determine Y result and write tests expecting Y to be true. Now with the advent of hooks, side-effects are much more likely to be in all of our components. This makes react components impure and difficult to test as individual units. This movement started primarily with the shift to hooks. > Anyway I still very much value the concepts behind sagas so thanks for great work. Thanks!
noob_07 4y ago
The only off putting thing in redux-saga for me was the over use of verbs in the API. The `put, call, take, takeEvery, all`. That makes me somehow a little tense. I don't agree with the testing part though, We used helpers like `runSaga` method to get this done easily, also generator value can also be passed in using `generator.next(//value//)` if I remember correctly.

cageface 4y ago

I had to rescue a saga based project that went badly off the rails and it was some of the hardest code I’ve ever had to debug in any language. Code flow was very difficult to reason about and forget about trying to use stack traces.

tylerchurch 4y ago
Yeah I had to rescue a buggy React Native app where the devs put every backend call into sagas. It was a pain to debug and I’ve since almost entirely ripped sagas out. It’ll be a good day when I can delete it as a dependency.

pgorczak 4y ago

Async generators similarly open up different ways to program complex / multi step user interactions. Instead of creating “state machine” objects that mutate on every input, you can have async functions aka coroutines that iterate over user inputs, making the flow of an interaction much more explicit.

isakkeyten 4y ago

Be careful. You will summon acemarke with this comment.

acemarke 4y ago
HAH! and ironically I read this literally 10 minutes after you posted it :) dons maintainer hat <ObligatoryResponse> We've been generally recommending against use of sagas for years - they're a power tool, and very few apps need that. They're also a bad fit for basic data fetching. Today, Redux Toolkit's "RTK Query" API solves the data fetching and caching use case, and the RTK "listener" middleware solves the reactive logic use case with a simpler API, smaller bundle size, and better TS support. Resources: - https://redux.js.org/tutorials/essentials/part-7-rtk-query-basics https://redux.js.org/tutorials/essentials/part-7-rtk-query-b... - https://redux-toolkit.js.org/rtk-query/overview https://redux-toolkit.js.org/rtk-query/overview - https://redux-toolkit.js.org/api/createListenerMiddleware https://redux-toolkit.js.org/api/createListenerMiddleware - https://blog.isquaredsoftware.com/2022/06/presentations-modern-redux-rtk/ https://blog.isquaredsoftware.com/2022/06/presentations-mode... </ObligatoryResponse>
- whilenot-dev 4y ago
  I'll use your nice response for an actual question/remark, gotcha! =) Recently I had a look at the kubeshop-dashboard repo[1] and their use of the RTK Query API[2]. When I write the boilerplate for any SPA nowadays, I usually like to merge any fetching logic with the lib-specific notification/toast-methods, in order to render something to the user about any reached warning- or error-timeouts for each ongoing fetch by default. Meaning: - every new fetch would start a timer - after 10secs a warning-notification is shown "a fetch takes longer than expected..." - and after 30secs the AbortController signals the cancelling of the ongoing fetch and an error-notification is shown "fetch took to long. click to try again." The implementation of react-query, its "hook-yfied" nature, makes it super easy to wrap it and merge it with the component-lib to create such a thing. I just need to wrap its provided hooks (useQuery, useMutation) with "hook-creators" (I usually call them createQueryHook and createMutationHook) and don't need to dive into any of its implementation specific details. But createApi, as provided by RTK Query API, makes this quite a bit harder, or so it seems to me at least. How would you wrap createApi to provide such a functionality for every fetch by default? [1]: https://github.com/kubeshop/testkube-dashboard https://github.com/kubeshop/testkube-dashboard [2]: https://github.com/kubeshop/testkube-dashboard/tree/main/src/services https://github.com/kubeshop/testkube-dashboard/tree/main/src...

qudat 4y ago

> it's hard to test (despite what the documentation claims). It's highly declarative, and such code seems hard to test. redux-saga member here. If we concede that mocks are inherently difficult to get right and maintain, often requiring libraries or testing frameworks to do a lot of the heavy lifting, then I would argue testing sagas is a breeze in comparison. The real magic behind redux-saga and its use of generators is the end-user functions do not have side-effects at all, they merely describe what those side-effects ought to look like. The library activates the side-effects in its runtime, the end-user just yields to json objects. So in order to test sagas, all you need is to run the generator and make sure it yields the things you expect it to yield. https://bower.sh/simplify-testing-async-io-javascript https://bower.sh/simplify-testing-async-io-javascript Having said all that, because the react world has heavily shifted towards hooks -- which explicitly make the view layer impure and hard to unit test -- a bunch of tooling has come out to prefer integration testing. In particular, testing user flows and evaluating what the user sees. In this paradigm, testing individual sagas or even react components is not nearly as valuable.

sktrdie 4y ago
First of all, sagas are an amazing concept that I still cherish even if I don’t use them anymore (hype not there?). Regarding the hooks comment I’m not sure I follow. Surely components are also idempotent (if you skip useEffect) and should be replayable - that’s at least how I think react refresh can manage to keep state intact during file changes in development. Anyway I still very much value the concepts behind sagas so thanks for great work.
- qudat 4y ago
  > Regarding the hooks comment I’m not sure I follow. Surely components are also idempotent (if you skip useEffect) and should be replayable - that’s at least how I think react refresh can manage to keep state intact during file changes in development. We used to have the concept of smart and dumb components, with dumb components we could test if we provide X props we could determine Y result and write tests expecting Y to be true. Now with the advent of hooks, side-effects are much more likely to be in all of our components. This makes react components impure and difficult to test as individual units. This movement started primarily with the shift to hooks. > Anyway I still very much value the concepts behind sagas so thanks for great work. Thanks!

noob_07 4y ago

The only off putting thing in redux-saga for me was the over use of verbs in the API. The `put, call, take, takeEvery, all`. That makes me somehow a little tense. I don't agree with the testing part though, We used helpers like `runSaga` method to get this done easily, also generator value can also be passed in using `generator.next(//value//)` if I remember correctly.