how to know if i should use redux for my application or any other alternative?

Question

I am new to react native and mobile development world. I am developing a mobile application with react native, it's basically an entreprise management app for HR management, storage management, projects and tasks management, clients management, and it contains user authentification with different roles.

The backend and database are already developed. What are my options to handle data and what are the difference between them ?

I did researches and i am wondering if i should use redux in this application or is there any other alternatives because apparently redux is very hard and i only have 2 months to finish the project

Answer 1

I can recommend mobx. It uses dark magic and can be hard to debug, but it works well most of the time.

Redux is not hard. The concept is rather easy, but it requires too much boilerplate IMHO.

Answer 2

From: Mateusz Grzesiukiewicz Book “Hands-On Design Patterns with React Native” :

Comparing Redux and MobX

This section is highly influenced by Preethi Kasireddy's talk at React Conf 2017. Please spend half an hour and watch it. You can find the talk at https://www.youtube.com/watch?v=76FRrbY18Bs.

• Redux uses plain objects, while MobX wraps objects into Observables. You may expect me to mention some magic again—no. The brutal truth is that MobX comes at a cost. It needs to wrap observable data and add some weight to each single object or each member of a collection. It is fairly easy to look up just how much data: use console.log to see your observable collection.

• Redux manually tracks updates, whereas MobX automatically tracks updates.

• A Redux state is read-only and can be altered by dispatching an action, while a MobX state can be altered at any time, sometimes only by using actions exposed by your Store API. Also, in MobX, actions are not required. You can change state directly.

• In Redux, a state is typically normalized, or at least this is recommended. In MobX, your state is denormalized and computed values are nested.

• Stateless and stateful components: here it may seem difficult. Preethi Kasireddy, in the lecture linked in the preceding information box, mentioned that MobX can be used with smart components only. To some extent, this is true, but there is no distinction here from Redux. Both support presentational components, as these are completely decoupled from state management libraries!

• The learning curve—this is very subjective criteria. Some will find Redux easier, others will find MobX easier. The popular belief is that MobX is easier to learn. I'm an exception to this.

• Redux requires more boilerplate. Being more explicit, this is quite straightforward, but there are libraries that fix this if you don't care. No references will be provided here, as I recommend educated use.

• Redux is much easier to debug. This comes naturally with single flow and easy replay of messages. This is where Redux shines. MobX is more old-school here, a little harder to predict, and not so obvious, even to experienced users.

• Redux wins when it comes to scalability. MobX may pose some maintainability problems, especially in big projects with a lot of connections and a big domain.

• MobX is concise and shines in small, time-constrained projects. If you go to a hackathon, consider using MobX. In big, long-term projects, you would need a more opinionated approach on top of the freedom that MobX gives.

• MobX follows the Flux architecture and does not alter it as much as Redux does.

• Redux leans towards one global store (although can be used with many!), while MobX is quite flexible with the amount of stores and its examples usually demonstrate similar thinking to the early ideas of Flux.

While using Redux, you need to learn how to deal with different situations and how to structure things. When it comes to dealing with side effects especially, you will need to learn Redux Thunk and possibly Redux Saga, which will be introduced in the following chapter. In MobX, all of this is magically taken care of behind the scenes, using reactive streams. In this respect, MobX is opinionated, but takes one responsibility away from you.

While using Redux, you need to learn how to deal with different situations and how to structure things. When it comes to dealing with side effects especially, you will need to learn Redux Thunk and possibly Redux Saga. In MobX, all of this is magically taken care of behind the scenes, using reactive streams. In this respect, MobX is opinionated, but takes one responsibility away from you.

MobX is like system of roads for cars. You create a road map and let people drive. Some will cause accidents, some will drive carefully. Some roads may be limited to one-way to restrict traffic a little, or even shaped in a certain way to allow easier reasoning about the car flow, as in Manhattan. Redux, on the other hand, is like a train. Only one train can move on a track at a time. If there are a few at the same moment and something is holding up the one in front, every other train waits behind, just like in a subway station. Sometimes trains need to transfer people as far as the other side of a continent, and this is also possible. All of this train flow is governed by one (distributed) agency that plans the movement and puts restrictions on the train flow.

Answer 3

TL;DR You are alone and you have 2 months, go with what you know*.

*In rare cases described below go with Redux.

It very much depends on several points:

Expected live of the app

If you expect the app to be done in 2 months and to never ever look at it again, then Redux or basically any other architecture pattern/library will be mostly a drag, especially for your case as you are a single developer on this project (from what I understand). Architecture is an investment, and from the kind that does not pay back in 2 man/months, maybe in a few man/years. As you are alone and the deadline is near I would advise you to just go with what you know*. From personal experience in a team of ~20 developers on >250K LOC codebase with very complex state management, we started to see the benefits >5 months after the initial introduction of Redux in the app.

*Except in the cases described below...

BE responses caching and depth of components

Redux solves response caching and props drilling problems (and others but these you might experience the most). In case you have to cache data from the BE while changing screens Redux can help there. As for boilerplate if you use RTK (Redux toolkit: https://redux-toolkit.js.org/) you will write a bit more than without Redux, for the same caching. If you will have a very deep component tree then Redux will simply remove the passing of props and callbacks down the tree, you will use selectors and actions instead which are not passed but just included in the component.

So if there is a big need for caching and/or there will be a lot of props drilling Redux might just pay off in that 2 months (not a high chance but maybe).

Complex state, Complex BE requests, complex error handling

By complex state, I mean something that has at least several states (ex: connected, disconnected, retrying, offline, permission problem, etc.) and non-trivial logic for transition between these states. For example you need to start some user interaction for permissions and the continue from where you left off.

By complex requests I mean at least several endpoints with retries required and maybe passing data from the response of one request to the input of the next. In this case, the state management will be hard and Redux might be a good solution for that. Also, error handling where you do not want to just show an error toast, but to retry on user request or similar might also be a point for Redux (I would not consider error handling alone as enough for going to Redux).