React/Redux concept Vs server call requests

Question

I am wondering what is the best design approach between using a big state (store) and sql request in database. Let's say you have a Todo CRUD application. You can save the Todos list in store within Redux implementation. What is the best approach if you want to make complex statistics on those TODOs: Reducers or sql requests?

For example, you want to get all todos for the current month:

1. Reducers/store approach
   You can get all the todos list from the store and filter todos by date to get all todos for the current month.
   • Pros:
     CRUD actions easy to manage, one state changes in the store (todos list)
     Low client/server traffics
   • Cons
     Business logic on client side
     client overhead for large data processing
2. Sql request approach:
   Complex request in database to get those todos and save the state 'currentMonthTodos' in the store. In this case you get your current month Todos list from currentMonthTodos state
   • Pros:
     Business logic on server side
     Reducing page load time for large datas
   • Cons
     Poor state management for CRUD actions
     High network traffic
     Size of the store grows up

Answer 1

Let's say you have a Todo CRUD application. You can save the Todos list in store within Redux implementation. What is the best approach if you want to make complex statistics on those TODOs: Reducers or sql requests?

Usually, real life applications you do with the Redux are medium or large scale. Simple CRUD applications you could do either way.

I guess when you mentioned the database (SQL requests) you considered Restful programming.

For the very simple applications, the Redux pattern doesn't have that much sense, unless you need advanced visual effects.

However, small applications do grow over time and can become medium scale fast, by adding more components.

Redux idea is excellent in cases we have a great number of application components that interact. In Redux these will be called the container components, and these are different from the simple presentational components that are also known as stateless functional components.

Having 2 components A and B you have just a few possible update chains.

A will update B and B will update A, or self-update (not including in here the possible updates from outside of the app).

With just three components interacting we have much more possible chains.

And with even more components it gets complicated. We eliminate the possible exponential interaction complexity with the Redux pattern. Redux pattern is similar to IDispatch, IObservable if you worked with these interfaces from some other programming languages.

One would be for spitting the actions, and the other for entering the listener's chain that exists inside the store.

We get very similar to the event driven approach in GUI applications — when you move the mouse you get the events.

In React components create actions. Sometimes a lot of actions. In fact, you may get so many actions in some cases so the application will freeze if you have the bad design.

Typically components should throttle the actions and there are great solutions in React for that.

So what are components in React Redux? From one side components are action dispatcher and on the another side they get the props, possible context, possible the application state or even local state. Finally, components may have the rendering logic. Sometimes components are just containers.

I just wrote this to represent the initial complexity of the Redux pattern while Restful applications are by design simple.

---

I think that this is the main factor you should take into account. Using Redux for the trivial TODO applications that will never grow the complexity may not be needed, so you may go with the Restful app.

---

https://egghead.io/lessons/javascript-redux-store-methods-getstate-dispatch-and-subscribe?course=getting-started-with-redux