Decision on Managing Anyc State in Redux & Redux Organization

[pdw207]

We need to make a decision and set up nextjs with Redux: A good example is here: https://github.com/zeit/next.js/tree/master/examples/with-redux

Are we using Saga, Redux Logic or Thunk? https://github.com/redux-observable/redux-observable 2,449 stars https://github.com/gaearon/redux-thunk 4,500 stars https://github.com/jeffbski/redux-logic 532 stars https://github.com/redux-saga/redux-saga 6,800 stars https://github.com/skellock/reduxsauce 178 stars

[pfarnach]

Here's a good overview of some of 3 of the mentioned middlewares: https://medium.com/react-native-training/redux-4-ways-95a130da0cdc#.y7w9wo3c0

I've personally only ever used redux-thunk and I've found it to be very simple and scalable. The source code is ~15 lines of code and requires that you return a function from your action creator -- that function gives you redux's dispatch() as a "funnel" to pass on your async data to the reducer.

I've heard good things about redux-saga and how it works well with testing your actions if that's a concern of ours, but that it's more "heavy-duty" in that it requires some knowledge of ES2015 generators.

redux-promise is nice and simple but not scalable so I wouldn't recommend it for any larger project.

[pdw207]

For me I've used redux-thunk and redux-saga. I like redux-thunk on small projects because its simple to understand and use and suggest we don't preemptively introduce complexity until/unless required.

[dorono]

I'm ok with redux-thunk if that's the consensus, especially since I am fairly new to the React ecosystem, so whatever will make it easiest for folks such as myself and others who will be joining the project over the coming months/years is probably going to outweigh any benefits from a more complex solution. Cool either way though.

[pfarnach]

Taking a step back, what sort of state do we intend to put into redux? Looking at the mocks, the UI component structure seems very simple, so is redux necessary [right now]?

[ignu]

Just to argue for the pros of redux:

• it's a known architecture, there's no reinventing the wheel.
• right now we're fetching data in EventList and passing props to EventCard. i don't think that plays nicely with being able to route to /events/:id
• forces immutability of state
• wealth of debugging tools including time traveling debugging

[pfarnach]

I'm a big fan of redux, I just want to make sure it's not adding unnecessary complexity to what is a relatively simple app. I'm happy either way -- I see a lot of projects jumping into redux by default, so it seemed like a good time to ask the question.

I'm not sure what you mean by the /events/:id route. How we store the data is separate from how we route to the event details page, right?

[jktravis]

I'm a fan of redux-logic. It really is a nice API, and from what I see it provides the best of all the async worlds. I'm currently using it for my day-job project. It allows you to use Promises, generators, or observables, has a dependency injection mechanism, auto dispatch success/failures, multi-dispatch mode, and more. I really like the auto-dispatch. I tend to setup my actual business logic in an API file, and call functions out of it from the "logic" file so as to keep the two loosely coupled.

For example:

import MyCoolApi from '../api/myCoolApi';

const testingLogic = createLogic({
  type: 'TESTING',
  latest: true,
  processOptions: {
    successType: 'TESTING_SUCCESS',
    failType: 'TESTING_FAILURE'
  },

  process({getState(), action}) {
    return MyCoolApi.doCoolAsyncStuff(getState().awesome, action.payload.stuff)
       .then(resp => MyCoolApi.doMoreAsyncStuffWithResponse(resp));
  }
});

This bit of code will only run with a TESTING type is dispatched. If the promise resolves, TESTING_SUCCESS is dispatched, and if it fails, TESTING_FAILURE is dispatched with an error:true flag. The payload of the error will be the reject message, if there is one.

You can also use action creators and even respond to multiple actions if you set type to an array.

The latest property tell redux-logic to debounce this request, which could be useful if we were doing something with drag'n'drop or something.

At any rate, I'm a big fan, even though it has the least stars.

Here's an article from the author describing it and the problem it solves.

Where do I put my business logic in a React-Redux application?