6 ms·

Yeah this is the problem with the React ecosystem. I'm intimately familiar with this stack and used to use redux with "duck" modules professionally, complete wi

Yeah this is the problem with the React ecosystem. I'm intimately familiar with this stack and used to use redux with "duck" modules professionally, complete with sagas and epics, and rxjs and the whole kitten, so it's not that I don't understand all the terms and am just overwhelmed. It's just that once you stop using Redux, it becomes so much easier to build and manage your app, and you don't even realize how much you're complicating everything by using sagas and actions creators and reducers and selectors and.. and.. and. You don't even realize how bad the boilerplate is until it's all gone. With svelte and some writable and readable stores, I can build apps in a fraction of the time because every time I want to make a change I don't have to start with an action creator, than integrate that into the reducer, then write a selector, then pull it into my component. Oh I guess I need to write an epic with rxjs to fetch the data. Svelte has 2 primitives that replace all of this: readable and writable. You can create a writable store and you call `.update` or `.set` like react setState. Want to separate your update logic from your component logic like in redux? Easy, just export functions to update the store instead of calling `.update` in your components. Then, there's readable. Now, readable can be used like a reselect selector, but it's also far more powerful. You can subscribe to changes from a writable, or even other readable stores. You can create a readable that fetches your data. You can create a readable that subscribes to firestore collection or document. You can make a readable that combines data from multiple sources. It's all clear and composable. And I didn't have to write an action creator with an action constant called `LOADING_PRODUCTS`, and one called `LOADED_PRODUCTS`, and then one called `UPDATED_PRODUCTS`, and for good measure we should also create an action "PRODUCTS_REQUEST_FAILED" that we'll emit from the epic.

brundolf 6y ago
> Svelte has 2 primitives that replace all of this: readable and writable. You can create a writable store and you call `.update` or `.set` like react setState. Want to separate your update logic from your component logic like in redux? Easy, just export functions to update the store instead of calling `.update` in your components. This sounds very similar to the experience of using MobX. I evangelize it as an alternative to Redux every chance I get; it's incredible how practical and pleasant it is to work with.
- gkaemmer 6y ago
  I actually came to this thread expecting more people to call out MobX. When I use MobX with react, I find it to be as simple and _fun_ as the author finds svelte. Most of the problems people tend to raise with React are problems that are solved by observable state objects. I also evangelize it whenever I can -- I don't want MobX to be forever doomed to its status as a cult hit!
  - brundolf 6y ago
    It's baffling to me how distant of a second it is in terms of popularity. Instead of forcing you to contort your program into a special paradigm in order to deal with reactivity in a sane way, it simply makes reactivity a non-concern (while remaining pretty simple and predictable when you do actually care to dig beneath the magic). You can write code in a way that's natural and simply not think about reactivity most of the time, and you'll even get better performance in many cases because of the highly-granular pub/sub that it sets up automatically. I cannot praise this paradigm enough.
    - orangecat 6y ago
      And then there's Vue.js which essentially has MobX functionality built in. When you want to update the state, you just...update the state, which can be a plain JS object that knows nothing about the front-end framework. I've used it for several medium-size projects and haven't gotten close to needing anything like Redux or Vuex.
      - brundolf 6y ago
        Yeah, although when I played with Vue a couple years ago it seemed like it wasn't quite as powerful as MobX (particularly when you start stacking up a graph of computed values, or when you want to create side-effects of your own). But definitely a similar idea.
      - phaedryx 6y ago
        I was a fan of MobX+React until I to a look a Vue when version 3 came out. Now I'm a Vue fan and what I was doing before feels like overkill.
williamdclt 6y ago
To be fair, you're criticizing Redux more than React. And even then, you're criticizing a specific pattern of using Redux: redux-toolkit melts away all the boilerplate you're talking about, and you could use something else than Redux if you wanted. I agree that React folks (me included) tend to reach out to Redux much too soon, though.
alfonsodev 6y ago
I also don't like having all those constants like LOADING_PRODUCTS ... And I don't have them, instead this is how you create a type safes actions with typesafe-actions package. export const signIn = { request: createAction("auth/signin/request")(), success: createAction("auth/signin/success")<{ user: User }>(), error: createAction("auth/signin/error")<Error>(), }; getType is a function from typesafe-actions as well. Not trying to sell you on Redux, just to address your point about the constants. About having to write many Epics, well, end of the day, all the Epics have this shape. export const signInEpic = (action$: Observable<Action>) => action$.pipe( filter(isActionOf(signIn.request)), switchMap(() => from(signInLogic()).pipe( map((user: User) => { return signIn.success({ user }); }), catchError((error) => of(signIn.error(error))) ) ) ); isActionOf is another typesafe-actions function... I'm not claiming it's superior approach or faster, it's an approach that worked for me for medium/large apps, to collaborate with other developers. I'm pretty sure you are right about the Svelte cool things you saying I wish I had more time to look into it.
- acemarke 6y ago
  We specifically recommend using our official Redux Toolkit package, rather than `typesafe-actions`. RTK is already written in TS and designed for a solid TS usage experience: https://redux-toolkit.js.org https://redux-toolkit.js.org
  - skvark 6y ago
    Redux Toolkit is great and removes most of the usual Redux boilerplate which seems to be the most often used argument against Redux. Additionally, I usually use a function which uses createEntityAdapter, createSlice and createAsyncThunk methods to create Ducks bundles for each REST API resource automatically. As a result I get all async action creators, reducers and basic selectors for some REST API resource with a couple of lines of code.
    - acemarke 6y ago
      If you like the stuff in RTK so far, I think you're going to like our upcoming "RTK Query" API, which adds a React Query-inspired data fetching abstraction: https://rtk-query-docs.netlify.app https://rtk-query-docs.netlify.app We're working on finalizing that API and will be merging the functionality and docs back into RTK itself for an upcoming RTK release: https://github.com/rtk-incubator/rtk-query/issues/175 https://github.com/rtk-incubator/rtk-query/issues/175
Aeolun 6y ago
You should try redux toolkit
acemarke 6y ago
I do get the arguments that you're making here about Svelte, and don't disagree. That said, "Modern Redux" code is very different than what you've probably seen even just a couple years ago. We've introduced newer APIs like Redux Toolkit, which is a set of utilities that provide a light abstraction to simplify the most common Redux tasks, and the React-Redux hooks API, which is generally easier to use than the traditional connect API. If you get a chance, I strongly recommend reading through the newly rewritten official tutorials in the Redux docs, which have been specifically designed to show both how Redux works and show our recommended practices: - "Redux Essentials" tutorial [0]: teaches "how to use Redux, the right way", by building a real-world app using Redux Toolkit - "Redux Fundamentals" tutorial [1]: teaches "how Redux works, from the bottom up", by showing how to write Redux code by hand and why standard usage patterns exist, and how Redux Toolkit simplifies those patterns The older patterns shown in almost all other tutorials on the internet are still valid, but not how we recommend writing Redux code today. You should also read through the Redux "Style Guide" docs page [2], which explains our recommended patterns and best practices. Following those will result in better and more maintainable Redux apps. Finally, we've got an upcoming "RTK Query" API that we're finalizing and adding to Redux Toolkit (inspired by tools like React Query and Apollo) , which should drastically simplify the data fetching story for Redux apps. [0] https://redux.js.org/tutorials/essentials/part-1-overview-concepts https://redux.js.org/tutorials/essentials/part-1-overview-co... [1] https://redux.js.org/tutorials/fundamentals/part-1-overview https://redux.js.org/tutorials/fundamentals/part-1-overview [2] https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide [3] https://rtk-query-docs.netlify.app https://rtk-query-docs.netlify.app
- dmitriid 6y ago
  I can agree on redux hooks being a better alternative to the whole mapToState cycle. But if you go into the new tutorials, they quickly devolve into the same old: https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re... Oh, look, slices, and thunks, and asyncThunks, and extraReducers, and adapters, and fifteen files to tie all this together for every small piece of api or data that you want to send around. Most of it just comes from the fact that Javascript doesn't have a good built-in way of doing these cycles fo data/store updates. And still, I don't know where the sweet spot of Redux it: it's an overkill for small apps, it's unmanageable in big apps. However, I will concede that the new hooks like `useDispatch` are nice
tomduncalf 6y ago
>You don't even realize how bad the boilerplate is until it's all gone I 100% agree with this, I also started out working with Redux in the fairly early days of React and while I do feel that I did learn a lot from it and have used Redux-inspired patterns for certain parts of applications since then, the productivity gains I got from switching to MobX for state management can't be overstated. Sure, you could argue it's less "clean" or whatever, but honestly 99% of the time it just works, and I'm happy to have the 1% of time where you're debugging where you forgot to add "observable" or whatever in exchange for the 99% productivity boost. Svelte does look really interesting and follows a similar kind of model to how I work with React and MobX, and does away with some boilerplate/gotchas. My main concern using it would be around maturity of libraries... while it does seem pretty batteries-included, I have got used to being able to just pull in a library for x, y or z in React and I'd be worried if I started a big Svelte project, I might find myself kicking myself down the line e.g. if I need some component (data table or whatever) that has a mature option available in React. Perhaps people who've worked with Svelte professionally can comment on whether this is a valid concern?

brundolf 6y ago

> Svelte has 2 primitives that replace all of this: readable and writable. You can create a writable store and you call `.update` or `.set` like react setState. Want to separate your update logic from your component logic like in redux? Easy, just export functions to update the store instead of calling `.update` in your components. This sounds very similar to the experience of using MobX. I evangelize it as an alternative to Redux every chance I get; it's incredible how practical and pleasant it is to work with.

gkaemmer 6y ago
I actually came to this thread expecting more people to call out MobX. When I use MobX with react, I find it to be as simple and _fun_ as the author finds svelte. Most of the problems people tend to raise with React are problems that are solved by observable state objects. I also evangelize it whenever I can -- I don't want MobX to be forever doomed to its status as a cult hit!
- brundolf 6y ago
  It's baffling to me how distant of a second it is in terms of popularity. Instead of forcing you to contort your program into a special paradigm in order to deal with reactivity in a sane way, it simply makes reactivity a non-concern (while remaining pretty simple and predictable when you do actually care to dig beneath the magic). You can write code in a way that's natural and simply not think about reactivity most of the time, and you'll even get better performance in many cases because of the highly-granular pub/sub that it sets up automatically. I cannot praise this paradigm enough.
  - orangecat 6y ago
    And then there's Vue.js which essentially has MobX functionality built in. When you want to update the state, you just...update the state, which can be a plain JS object that knows nothing about the front-end framework. I've used it for several medium-size projects and haven't gotten close to needing anything like Redux or Vuex.
    - brundolf 6y ago
      Yeah, although when I played with Vue a couple years ago it seemed like it wasn't quite as powerful as MobX (particularly when you start stacking up a graph of computed values, or when you want to create side-effects of your own). But definitely a similar idea.
    - phaedryx 6y ago
      I was a fan of MobX+React until I to a look a Vue when version 3 came out. Now I'm a Vue fan and what I was doing before feels like overkill.

williamdclt 6y ago

To be fair, you're criticizing Redux more than React. And even then, you're criticizing a specific pattern of using Redux: redux-toolkit melts away all the boilerplate you're talking about, and you could use something else than Redux if you wanted. I agree that React folks (me included) tend to reach out to Redux much too soon, though.

alfonsodev 6y ago

I also don't like having all those constants like LOADING_PRODUCTS ... And I don't have them, instead this is how you create a type safes actions with typesafe-actions package. export const signIn = { request: createAction("auth/signin/request")(), success: createAction("auth/signin/success")<{ user: User }>(), error: createAction("auth/signin/error")<Error>(), }; getType is a function from typesafe-actions as well. Not trying to sell you on Redux, just to address your point about the constants. About having to write many Epics, well, end of the day, all the Epics have this shape. export const signInEpic = (action$: Observable<Action>) => action$.pipe( filter(isActionOf(signIn.request)), switchMap(() => from(signInLogic()).pipe( map((user: User) => { return signIn.success({ user }); }), catchError((error) => of(signIn.error(error))) ) ) ); isActionOf is another typesafe-actions function... I'm not claiming it's superior approach or faster, it's an approach that worked for me for medium/large apps, to collaborate with other developers. I'm pretty sure you are right about the Svelte cool things you saying I wish I had more time to look into it.

acemarke 6y ago
We specifically recommend using our official Redux Toolkit package, rather than `typesafe-actions`. RTK is already written in TS and designed for a solid TS usage experience: https://redux-toolkit.js.org https://redux-toolkit.js.org
- skvark 6y ago
  Redux Toolkit is great and removes most of the usual Redux boilerplate which seems to be the most often used argument against Redux. Additionally, I usually use a function which uses createEntityAdapter, createSlice and createAsyncThunk methods to create Ducks bundles for each REST API resource automatically. As a result I get all async action creators, reducers and basic selectors for some REST API resource with a couple of lines of code.
  - acemarke 6y ago
    If you like the stuff in RTK so far, I think you're going to like our upcoming "RTK Query" API, which adds a React Query-inspired data fetching abstraction: https://rtk-query-docs.netlify.app https://rtk-query-docs.netlify.app We're working on finalizing that API and will be merging the functionality and docs back into RTK itself for an upcoming RTK release: https://github.com/rtk-incubator/rtk-query/issues/175 https://github.com/rtk-incubator/rtk-query/issues/175

Aeolun 6y ago

You should try redux toolkit

acemarke 6y ago

I do get the arguments that you're making here about Svelte, and don't disagree. That said, "Modern Redux" code is very different than what you've probably seen even just a couple years ago. We've introduced newer APIs like Redux Toolkit, which is a set of utilities that provide a light abstraction to simplify the most common Redux tasks, and the React-Redux hooks API, which is generally easier to use than the traditional connect API. If you get a chance, I strongly recommend reading through the newly rewritten official tutorials in the Redux docs, which have been specifically designed to show both how Redux works and show our recommended practices: - "Redux Essentials" tutorial [0]: teaches "how to use Redux, the right way", by building a real-world app using Redux Toolkit - "Redux Fundamentals" tutorial [1]: teaches "how Redux works, from the bottom up", by showing how to write Redux code by hand and why standard usage patterns exist, and how Redux Toolkit simplifies those patterns The older patterns shown in almost all other tutorials on the internet are still valid, but not how we recommend writing Redux code today. You should also read through the Redux "Style Guide" docs page [2], which explains our recommended patterns and best practices. Following those will result in better and more maintainable Redux apps. Finally, we've got an upcoming "RTK Query" API that we're finalizing and adding to Redux Toolkit (inspired by tools like React Query and Apollo) , which should drastically simplify the data fetching story for Redux apps. [0] https://redux.js.org/tutorials/essentials/part-1-overview-concepts https://redux.js.org/tutorials/essentials/part-1-overview-co... [1] https://redux.js.org/tutorials/fundamentals/part-1-overview https://redux.js.org/tutorials/fundamentals/part-1-overview [2] https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide [3] https://rtk-query-docs.netlify.app https://rtk-query-docs.netlify.app

dmitriid 6y ago
I can agree on redux hooks being a better alternative to the whole mapToState cycle. But if you go into the new tutorials, they quickly devolve into the same old: https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re... Oh, look, slices, and thunks, and asyncThunks, and extraReducers, and adapters, and fifteen files to tie all this together for every small piece of api or data that you want to send around. Most of it just comes from the fact that Javascript doesn't have a good built-in way of doing these cycles fo data/store updates. And still, I don't know where the sweet spot of Redux it: it's an overkill for small apps, it's unmanageable in big apps. However, I will concede that the new hooks like `useDispatch` are nice

tomduncalf 6y ago

>You don't even realize how bad the boilerplate is until it's all gone I 100% agree with this, I also started out working with Redux in the fairly early days of React and while I do feel that I did learn a lot from it and have used Redux-inspired patterns for certain parts of applications since then, the productivity gains I got from switching to MobX for state management can't be overstated. Sure, you could argue it's less "clean" or whatever, but honestly 99% of the time it just works, and I'm happy to have the 1% of time where you're debugging where you forgot to add "observable" or whatever in exchange for the 99% productivity boost. Svelte does look really interesting and follows a similar kind of model to how I work with React and MobX, and does away with some boilerplate/gotchas. My main concern using it would be around maturity of libraries... while it does seem pretty batteries-included, I have got used to being able to just pull in a library for x, y or z in React and I'd be worried if I started a big Svelte project, I might find myself kicking myself down the line e.g. if I need some component (data table or whatever) that has a mature option available in React. Perhaps people who've worked with Svelte professionally can comment on whether this is a valid concern?