3 ms·

Tbh if you're living in React-land and understand Redux, useReducer with useContext has subsumed the need for it in nearly all cases for myself and my team. Fo

by girvo 5y ago

Tbh if you're living in React-land and understand Redux, useReducer with useContext has subsumed the need for it in nearly all cases for myself and my team. For the parts it doesn't match, truly global stuff or tonnes of mutation, MobX is nicer out of the box than Redux. Redux can be just as nice and in some ways more powerful, but thats only after installing and configuring X amount of middlewares, with all the type confusion that can add :(

arsome 5y ago
Interesting, I did look at MobX briefly but pretty quickly concluded it seemed like overkill for our use case where Redux, Redux Toolkit and Thunk would pretty much solve everything we needed and seemed comparatively simple to follow, I'll definitely take a look into useReducer and useContext though, that looks like a potentially viable option for the majority of cases.
- chrisweekly 5y ago
  I've got experience with MobX (from about 3y ago) and more recent experience with RTK. I still feel that MobX is easier to reason about -- but RTK is a big improvement over vanilla Redux. /$.02
  - acemarke 5y ago
    Out of curiosity, any particular concerns with RTK? Also interested in hearing any specifics about how MobX is "easier to reason about" for you.
acemarke 5y ago
Fortunately, you no longer need to "install a bunch of middleware" yourself - Redux Toolkit's `configureStore` gives you a good default setup out of the box [0], and we have TypeScript usage guidelines that infer all the needed state and dispatch types automatically [1] It's also worth noting that there are some significant difference between `useReducer+useContext` and Redux. Not saying those are bad and that you should avoid them : ) just that it's important to understand the intended use cases and technical behavior differences [2]. [0] https://redux.js.org/tutorials/fundamentals/part-8-modern-redux#store-setup https://redux.js.org/tutorials/fundamentals/part-8-modern-re... [1] https://redux.js.org/recipes/usage-with-typescript https://redux.js.org/recipes/usage-with-typescript [2] https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
- girvo 5y ago
  You bet there’s a big difference! In my experience, too many teams misunderstood what Redux is excellent at, and made a mess of things due to that misunderstanding. In those teams, useReducer alone gets us 80% of the way there, useContext combined with a well constructed reducer solves another 10-15% — and for most of the projects I’ve worked on across different teams with differing skill sets, often 100%. I’m glad to hear the Typescript inference issues I ran into a year, year and a half ago are solved. That wasn’t Redux’s fault per se, but composing middleware in such a way that the types flowed through correctly was such a hassle previously. Nice to hear it’s better now
  - acemarke 5y ago
    Yep, my recurring theme is "take the time to understand the use cases and tradeoffs of the tools you're looking at, and pick whatever actually solves _your_ problems". Btw, it is actually possible to use Redux Toolkit's `createSlice` API to create reducers just for passing to `useReducer`, even if you don't have a Redux store in your app - after all, reducers are _just_ functions. I've done this several times myself for cases where I wanted a well-TS-typed reducer with some complex logic in a plain React app. And yeah, my co-maintainer Lenz Weber is a TS genius, and has done an amazing amount of work over the last couple years to improve our TS handling in a lot of cases.

by girvo 5y ago

arsome 5y ago

Interesting, I did look at MobX briefly but pretty quickly concluded it seemed like overkill for our use case where Redux, Redux Toolkit and Thunk would pretty much solve everything we needed and seemed comparatively simple to follow, I'll definitely take a look into useReducer and useContext though, that looks like a potentially viable option for the majority of cases.

chrisweekly 5y ago
I've got experience with MobX (from about 3y ago) and more recent experience with RTK. I still feel that MobX is easier to reason about -- but RTK is a big improvement over vanilla Redux. /$.02
- acemarke 5y ago
  Out of curiosity, any particular concerns with RTK? Also interested in hearing any specifics about how MobX is "easier to reason about" for you.

acemarke 5y ago

Fortunately, you no longer need to "install a bunch of middleware" yourself - Redux Toolkit's `configureStore` gives you a good default setup out of the box [0], and we have TypeScript usage guidelines that infer all the needed state and dispatch types automatically [1] It's also worth noting that there are some significant difference between `useReducer+useContext` and Redux. Not saying those are bad and that you should avoid them : ) just that it's important to understand the intended use cases and technical behavior differences [2]. [0] https://redux.js.org/tutorials/fundamentals/part-8-modern-redux#store-setup https://redux.js.org/tutorials/fundamentals/part-8-modern-re... [1] https://redux.js.org/recipes/usage-with-typescript https://redux.js.org/recipes/usage-with-typescript [2] https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

girvo 5y ago
You bet there’s a big difference! In my experience, too many teams misunderstood what Redux is excellent at, and made a mess of things due to that misunderstanding. In those teams, useReducer alone gets us 80% of the way there, useContext combined with a well constructed reducer solves another 10-15% — and for most of the projects I’ve worked on across different teams with differing skill sets, often 100%. I’m glad to hear the Typescript inference issues I ran into a year, year and a half ago are solved. That wasn’t Redux’s fault per se, but composing middleware in such a way that the types flowed through correctly was such a hassle previously. Nice to hear it’s better now
- acemarke 5y ago
  Yep, my recurring theme is "take the time to understand the use cases and tradeoffs of the tools you're looking at, and pick whatever actually solves _your_ problems". Btw, it is actually possible to use Redux Toolkit's `createSlice` API to create reducers just for passing to `useReducer`, even if you don't have a Redux store in your app - after all, reducers are _just_ functions. I've done this several times myself for cases where I wanted a well-TS-typed reducer with some complex logic in a plain React app. And yeah, my co-maintainer Lenz Weber is a TS genius, and has done an amazing amount of work over the last couple years to improve our TS handling in a lot of cases.