18 ms·

For those looking for powerful async coroutines in the browser: The combination of typescript+redux+redux-saga is also quite powerful. Redux-saga uses generato

For those looking for powerful async coroutines in the browser: The combination of typescript+redux+redux-saga is also quite powerful. Redux-saga uses generator coroutines to handle all sorts of asynchronous tasks.

Aeolun 5y ago
I think you can do anything in Redux Saga without either Redux or React.
- bayesian_horse 5y ago
  There is power in the combination. When you think about needing sagas, you probably need sophisticated state management. Redux is a popular and battle-tested choice. Just as React is a popular and battle tested choice.
- eole666 5y ago
  I think you can do anything in Javascript without either Redux Saga or Redux or React.
  - surajs 5y ago
  - bayesian_horse 5y ago
    Yes, of course. It is possible. And you could also write everything in C and compile it to Webassembly. I don't know why I often get these pedantic "disagreements" even though this is no disagreement at all. There are very valid reasons why virtual DOM systems (and similar approaches like Svelte) are so popular: For any not-completely-basic use-case they are easier to manage and faster. React is a popular and battle-tested choice. Once you get the hang of it, it's a well thought out system, and you can get a lot of advice and wisdom about it for free. Maybe React is so unpopular with the pedantics here because it is so popular in the real world? And Redux is one way - not the only way - to implement a pattern that is a functional programming alternative to the MVC pattern. An alternative I very much prefer. It is extremely powerful for moderate to complex cases, and then the boilerplate can be kept manageable and appropriate for the required complexity. I found that it is performant, easy to read, easy to extend and easy to debug. You can do all of that in Javascript, but my experience is that it is in general a lot more painful. It is harder to maintain and harder to bring other people on board. The only time this "I don't use no stinking framework" approach doesn't completely backfire is in smaller projects or when self-rolled frameworks emerge out of the "no framework" code base. I try to keep my ego out of programming. That also means that dissing on frameworks "just because I can survive without them" isn't productive.
jokethrowaway 5y ago
Well, you're completely OT, but I started hating frontend development exactly when redux + sagas started becoming popular. Don't get me wrong, Elm has a very similar architecture but it's pleasant to use. The idea is cool, the implementation of redux and sagas is a terrible boilerplate mess. More recently, with react hooks + async you can model something similar without having to use redux or sagas. Redux hook syntax is also a step forward, albeit not very useful now that we have context and reducers.
- bayesian_horse 5y ago
  I think I've been where you are. You may also want to check out Fable. Anyway, I maintain a very complex SPA, where the react+hooks+async approach (and whatever there was before hooks) backfires. Hooks like useEffect itself turn into event handlers (Chains of useEffect clauses triggering each other's dependencies, sometimes across multiple components), and component composition and rendering becomes basically a way to declare async work flows. At some point this is very hard to follow and maintain, and this is where redux and saga come in. Saga allows me to cut down on the boilerplate and define the async logic in an almost synchronous manner, once I got the hang of it. I also don't see how saga is much boilerplate when used right. Also: Use createSelector and useSelector for almost everything. A selector doesn't just reduce the store's data, it can also perform computations and "elevate" the data from serializable stuff to fancier class instances (using 3rd part libraries). Composing graphs of selectors means extracting much of the display logic and computing out of the components, and it also means faster applications because of memoization. But the point is you really need to use every part of the stack to find the sweet spot: Typescript (with ActionType etc), Thunks (for simpler async tasks, but optional), createAction (for typing mainly), createSelector, and optionally/ideally Redux Toolkit and RTK Query.

Aeolun 5y ago

I think you can do anything in Redux Saga without either Redux or React.

bayesian_horse 5y ago
There is power in the combination. When you think about needing sagas, you probably need sophisticated state management. Redux is a popular and battle-tested choice. Just as React is a popular and battle tested choice.
eole666 5y ago
I think you can do anything in Javascript without either Redux Saga or Redux or React.
- surajs 5y ago
- bayesian_horse 5y ago
  Yes, of course. It is possible. And you could also write everything in C and compile it to Webassembly. I don't know why I often get these pedantic "disagreements" even though this is no disagreement at all. There are very valid reasons why virtual DOM systems (and similar approaches like Svelte) are so popular: For any not-completely-basic use-case they are easier to manage and faster. React is a popular and battle-tested choice. Once you get the hang of it, it's a well thought out system, and you can get a lot of advice and wisdom about it for free. Maybe React is so unpopular with the pedantics here because it is so popular in the real world? And Redux is one way - not the only way - to implement a pattern that is a functional programming alternative to the MVC pattern. An alternative I very much prefer. It is extremely powerful for moderate to complex cases, and then the boilerplate can be kept manageable and appropriate for the required complexity. I found that it is performant, easy to read, easy to extend and easy to debug. You can do all of that in Javascript, but my experience is that it is in general a lot more painful. It is harder to maintain and harder to bring other people on board. The only time this "I don't use no stinking framework" approach doesn't completely backfire is in smaller projects or when self-rolled frameworks emerge out of the "no framework" code base. I try to keep my ego out of programming. That also means that dissing on frameworks "just because I can survive without them" isn't productive.

jokethrowaway 5y ago

Well, you're completely OT, but I started hating frontend development exactly when redux + sagas started becoming popular. Don't get me wrong, Elm has a very similar architecture but it's pleasant to use. The idea is cool, the implementation of redux and sagas is a terrible boilerplate mess. More recently, with react hooks + async you can model something similar without having to use redux or sagas. Redux hook syntax is also a step forward, albeit not very useful now that we have context and reducers.

bayesian_horse 5y ago
I think I've been where you are. You may also want to check out Fable. Anyway, I maintain a very complex SPA, where the react+hooks+async approach (and whatever there was before hooks) backfires. Hooks like useEffect itself turn into event handlers (Chains of useEffect clauses triggering each other's dependencies, sometimes across multiple components), and component composition and rendering becomes basically a way to declare async work flows. At some point this is very hard to follow and maintain, and this is where redux and saga come in. Saga allows me to cut down on the boilerplate and define the async logic in an almost synchronous manner, once I got the hang of it. I also don't see how saga is much boilerplate when used right. Also: Use createSelector and useSelector for almost everything. A selector doesn't just reduce the store's data, it can also perform computations and "elevate" the data from serializable stuff to fancier class instances (using 3rd part libraries). Composing graphs of selectors means extracting much of the display logic and computing out of the components, and it also means faster applications because of memoization. But the point is you really need to use every part of the stack to find the sweet spot: Typescript (with ActionType etc), Thunks (for simpler async tasks, but optional), createAction (for typing mainly), createSelector, and optionally/ideally Redux Toolkit and RTK Query.