4 ms·

What is the goto for web if Redux is dead? I am not super knowledgeable about all the exact architectures, but I thought mobile was just starting to adopt the

What is the goto for web if Redux is dead? I am not super knowledgeable about all the exact architectures, but I thought mobile was just starting to adopt the redux architecture vs MVP, MVVM, etc

api_or_ipa 7y ago
A lot of people are saying that the new-but-not-really-new React Context API and useReducer hooks are sufficient to cover redux. My team isn't convinced, we see immense value because we're big fans of using Redux Saga-- a model that isn't well covered using Context or hooks, although we do use those APIs as well when needed.
- qudat 7y ago
  Shameless plug: https://github.com/neurosnap/use-cofx https://github.com/neurosnap/use-cofx Under the hood it uses [cofx](https://github.com/neurosnap/cofx https://github.com/neurosnap/cofx) which is a library I wrote to solve the need to write declarative side-effects without redux.
- WorldMaker 7y ago
  Hooks are definitely going to reduce a lot of greenfield project needs for a state library, which should be great for React ease of starting new projects. Something like Redux Saga, Redux Thunks, Redux Observable (my personal preference here), or what have you, are the higher order "toolsets" that Hooks alone aren't likely to replace yet. It may be the case that some of them are going to start targeting Hooks/Context more directly without "needing" an intermediary state engine like Redux, but it's also entirely possible that it will still remain a good reason to make a step change to a state engine like Redux when you find yourself needing higher-order coordination between components that libraries like Sagas, Thunks, or Observables can provide.
- RobertKerans 7y ago
  Suspense for data loading seems to cover that side of things quite well in the experiments I've tried with the current API. I use Sagas as well though, and Ive found them ok...really easy to test but feel very heavyweight and clunky; personally, I don't _really_ like the loading/error state to be handled by Redux: the more years I work on React/Redux app the more I prefer for a section of an app to be mounted -> triggering a fetch -> loading, show local loading UI -> {fails, show local UI|succeeds, dispatch success}. So Redux becomes a serializable normalized data cache that acts to store the results of disparate API calls and doesn't care at all much about the UI.
  - Klathmon 7y ago
    That's what I've been trending toward as well. There's a tremendous amount of work out there for how to get redux to completely handle async and branching methods, and I think the best solution for most cases is to not have it handle any of that. Keep your data fetching in normal everyday functions, have react components call those and funnel the data you need in the global store back to redux, and then have the components that need that data read it from the global store.
  - cozuya 7y ago
    What do you do if multiple components/"pages" that aren't even remotely connected need access to the results of an API call?
    - RobertKerans 7y ago
      The results are in the Redux store. I'm not sure I understand the question, why and how would multiple components be making the same fetch request at the same time? With what I'm describing, there is already a common state, if they just need access to that state they have access to it. Edit: If you do need to synchronise multiple async updates to that state that happen in a very short space of time & in an unknown order in a controlled way, then yeah something like sagas is a solid choice to exert control over that. But very often the user of the UI is only going to make one request [or one batched set of requests] -- eg I am working on an RN app at the minute, and each screen does need to fetch data. So I fetch in the component, it shows loading etc, then populates the store. If the user cancels what they're doing (navigate away for example), the component used to fetch unloads and no dispatch is made.
      - cozuya 7y ago
        I meant to reply to the guy above me who advocates component level fetch as opposed to using Redux sorry.
        RobertKerans 7y ago
        That was me! Component level fetch !== no Redux, that's not what I described; using Redux does not _mean_ you have to use one of the many libraries built to wrestle asynchronous fetching into Redux. I've got nothing against any of them, I've used almost every major one in my jobs over the last few years. But I (and the person who replied to me) both seem to feel the same way, that in many cases just fetching in React, in the component, is all that is needed, let the Redux application deal with marshalling the resultant state (which it is very good at)
- Androider 7y ago
  We started a greenfield project a few months ago and decided not use Redux and try the context API instead. In retrospect, that was a bad idea. Context is fine for a small app, but small apps tend not to stay small... and then you're stuck with the Yugo when you what you really need is a truck. In our main app we also use advanced features like what Slack is describing in their post, like having multiple Redux stores. We also combine stores from multiple sources (e.g. appStore = [...store1, ...store2, ...storeFromALibrary]. It's incredibly flexible.
- sbfriends 7y ago
  I think once you grok sagas, they're very difficult to replace. I think it's such a neat mental model to be able to dispatch global actions and having async tasks able to respond. I think it leads to nicer decoupling in components between UI & data.
Lazare 7y ago
I wouldn't say Redux is dead, but there are a number of alternatives. My team has switched from Redux to MobX for all new development, as the two libraries solve the same problems, and we find MobX a bit easier to work with for our specific use cases. There's nothing wrong with Redux; we just found that Redux based code tended to have a fair bit of boilerplate, and it wasn't as easy to maintain code using Redux as we would have liked. Every dev team has to find the right place to draw the line on implicit versus explicit, magic versus verbose, convention versus configuration. No real right or wrong answers. > I thought mobile was just starting to adopt the redux architecture I don't think so, no. The Redux architecture (ie, reducers, actions, etc.) is fairly specific and not universally loved. I would say that people are starting to really grasp the importance of solving the problems that Redux solves, however.
- leonidasv 7y ago
  I encourage you (and everyone facing the same problems) to take a look at Rematch (https://github.com/rematch/rematch https://github.com/rematch/rematch). It's Redux (the real Redux, you can even use it with the Redux-DevTools) with a MobX-like syntax. And already comes with async support. I think it's the best of both worlds.

What is the goto for web if Redux is dead? I am not super knowledgeable about all the exact architectures, but I thought mobile was just starting to adopt the redux architecture vs MVP, MVVM, etc

api_or_ipa 7y ago

A lot of people are saying that the new-but-not-really-new React Context API and useReducer hooks are sufficient to cover redux. My team isn't convinced, we see immense value because we're big fans of using Redux Saga-- a model that isn't well covered using Context or hooks, although we do use those APIs as well when needed.

qudat 7y ago
Shameless plug: https://github.com/neurosnap/use-cofx https://github.com/neurosnap/use-cofx Under the hood it uses [cofx](https://github.com/neurosnap/cofx https://github.com/neurosnap/cofx) which is a library I wrote to solve the need to write declarative side-effects without redux.
WorldMaker 7y ago
Hooks are definitely going to reduce a lot of greenfield project needs for a state library, which should be great for React ease of starting new projects. Something like Redux Saga, Redux Thunks, Redux Observable (my personal preference here), or what have you, are the higher order "toolsets" that Hooks alone aren't likely to replace yet. It may be the case that some of them are going to start targeting Hooks/Context more directly without "needing" an intermediary state engine like Redux, but it's also entirely possible that it will still remain a good reason to make a step change to a state engine like Redux when you find yourself needing higher-order coordination between components that libraries like Sagas, Thunks, or Observables can provide.
RobertKerans 7y ago
Suspense for data loading seems to cover that side of things quite well in the experiments I've tried with the current API. I use Sagas as well though, and Ive found them ok...really easy to test but feel very heavyweight and clunky; personally, I don't _really_ like the loading/error state to be handled by Redux: the more years I work on React/Redux app the more I prefer for a section of an app to be mounted -> triggering a fetch -> loading, show local loading UI -> {fails, show local UI|succeeds, dispatch success}. So Redux becomes a serializable normalized data cache that acts to store the results of disparate API calls and doesn't care at all much about the UI.
- Klathmon 7y ago
  That's what I've been trending toward as well. There's a tremendous amount of work out there for how to get redux to completely handle async and branching methods, and I think the best solution for most cases is to not have it handle any of that. Keep your data fetching in normal everyday functions, have react components call those and funnel the data you need in the global store back to redux, and then have the components that need that data read it from the global store.
- cozuya 7y ago
  What do you do if multiple components/"pages" that aren't even remotely connected need access to the results of an API call?
  - RobertKerans 7y ago
    The results are in the Redux store. I'm not sure I understand the question, why and how would multiple components be making the same fetch request at the same time? With what I'm describing, there is already a common state, if they just need access to that state they have access to it. Edit: If you do need to synchronise multiple async updates to that state that happen in a very short space of time & in an unknown order in a controlled way, then yeah something like sagas is a solid choice to exert control over that. But very often the user of the UI is only going to make one request [or one batched set of requests] -- eg I am working on an RN app at the minute, and each screen does need to fetch data. So I fetch in the component, it shows loading etc, then populates the store. If the user cancels what they're doing (navigate away for example), the component used to fetch unloads and no dispatch is made.
    - cozuya 7y ago
      I meant to reply to the guy above me who advocates component level fetch as opposed to using Redux sorry.
      - RobertKerans 7y ago
        That was me! Component level fetch !== no Redux, that's not what I described; using Redux does not _mean_ you have to use one of the many libraries built to wrestle asynchronous fetching into Redux. I've got nothing against any of them, I've used almost every major one in my jobs over the last few years. But I (and the person who replied to me) both seem to feel the same way, that in many cases just fetching in React, in the component, is all that is needed, let the Redux application deal with marshalling the resultant state (which it is very good at)
Androider 7y ago
We started a greenfield project a few months ago and decided not use Redux and try the context API instead. In retrospect, that was a bad idea. Context is fine for a small app, but small apps tend not to stay small... and then you're stuck with the Yugo when you what you really need is a truck. In our main app we also use advanced features like what Slack is describing in their post, like having multiple Redux stores. We also combine stores from multiple sources (e.g. appStore = [...store1, ...store2, ...storeFromALibrary]. It's incredibly flexible.
sbfriends 7y ago
I think once you grok sagas, they're very difficult to replace. I think it's such a neat mental model to be able to dispatch global actions and having async tasks able to respond. I think it leads to nicer decoupling in components between UI & data.

Lazare 7y ago

I wouldn't say Redux is dead, but there are a number of alternatives. My team has switched from Redux to MobX for all new development, as the two libraries solve the same problems, and we find MobX a bit easier to work with for our specific use cases. There's nothing wrong with Redux; we just found that Redux based code tended to have a fair bit of boilerplate, and it wasn't as easy to maintain code using Redux as we would have liked. Every dev team has to find the right place to draw the line on implicit versus explicit, magic versus verbose, convention versus configuration. No real right or wrong answers. > I thought mobile was just starting to adopt the redux architecture I don't think so, no. The Redux architecture (ie, reducers, actions, etc.) is fairly specific and not universally loved. I would say that people are starting to really grasp the importance of solving the problems that Redux solves, however.

leonidasv 7y ago
I encourage you (and everyone facing the same problems) to take a look at Rematch (https://github.com/rematch/rematch https://github.com/rematch/rematch). It's Redux (the real Redux, you can even use it with the Redux-DevTools) with a MobX-like syntax. And already comes with async support. I think it's the best of both worlds.