The original:
The Problems with Redux: Can React, MobX, and Realm save us?


By Erich Reich

First of all, I don’t hate Redux. It was developed by a very smart person to alleviate the problem of managing state in a single page application. And it did solve the problem. You can use Redux to wire state from a high-level store to each component, mapping only the state that the component needs.

In this article, I’d like to share some of our experiences in creating mobile applications for our customers. At Quantum Mob, our main webapps are written by React, and our mobile stack is written by React Native. React Native allows for much of the code to be shared between Android and iOS, and it makes it easier to reuse code from the web version of the product because it’s so similar to regular React.

The problem of story

There is no one perfect tool for all scenarios. Even if you like something, look at it clearly and objectively, especially if it’s advertised. Do you use it just because it’s cool, or because it’s the right choice? If something asks too much of itself, its publicity is not worth its weight in gold.

Don’t take my word for it, Dan Abramov wrote about Redux as an author, trying to make people stop and think about whether Redux is really a good fit for your project.

If you’re stressed out doing things the “Redux way,” it’s a sign that you or your team may be taking it too seriously. This is just one tool in your toolbox, a crazy experiment.


-Dan Abramov

With NPM, Node, and build tools (grunt, gulp, webpack…) The number of libraries and frameworks that need to be used in every project is exploding.

Do you need a processing date for your project? Why not use MomentJs? Do you want to deal with arrays? Plus things like Lodash or Ramda. If you don’t use Babel and Axios, and a good CSS framework, I can’t imagine that. Make sure to compile your homogeneous application, even if it’s just a Hello World application.

Problem 1: The learning curve

Redux introduces concepts that you need to spend time learning. You’ll need to browse through the documentation and go through the tutorial, because it’s not as simple as simply calling save and then retrieving the data.

Problem 2: Configuration

To use Redux, you need to design the Store, create multiple reducers and group them together. Then, using Connect or something else, configure mapStateToProps and mapDispatchToProps for each component that needs to interact with the Store.

Question 3: “Best Practices”

For each component, there is one file for JavaScript, one for styles, and one for JSX. Redux combines these things with the Action and Reducer files, and another pulls it all together. It’s Redux, but what if you only want to use it somewhere? For simple examples, the introduction of a powerful tool like Redux is overengineered.

An alternative to

Local State

Another alternative to Redux is to keep it simple and use local state for components. The idea is to keep the architecture simple from the start and add redux only when needed. Easy, right?

Here’s a good example from Dan of redux-style refactoring of a simple counter without Redux. Look at his article, it is well written, he is the authority on this topic.

MobX

MobX is newer than Redux and there’s definitely a lot of discussion going on right now. MobX promises all the functionality of Redux, but with less boilerplate code. This disadvantage is certainly minor and should not be expected to have the same level of control as Redux.

How does MobX work? Instead of focusing on changes and Reduce details, you can create the data model you want to store as a class and add it to MobX management using the @Observable decorator.

Another thing is that your objects don’t have to be normalized like Redux. This can be a good thing in some cases and a bad thing in others. For example, if you have a large array, you might run into performance problems when searching through it for a value, and you need to be aware of that.

If you want a quick look at MobX, you can start with this 4 minute video comparing to Redux.

Understanding MobX vs Redux

If you like what MobX officially says, check out their 10-minute intro. For a more objective view, here is an example of a developer using MobX.

Realm for React Native

Realm is another addition to the React World, but is currently only available with React Native. If you’re making a mobile app, it’s definitely worth a look. In addition to storing and managing your domain data, Realm also adds several data synchronization with the server, offline support, and encryption capabilities.

To help understand the rationale for using Realm, they came up with a real-world example of a quick start. Mobile applications typically perform multiple searches to store data locally to avoid additional calls that affect performance and provide a better user experience.

Video on Youtube: Realm

Realm should be thought of as a database integrated directly into your application. Provides good speed because object references are processed that have the same reference as the database and are saved to local storage, so no changes or searches are serialized or sent anywhere.

conclusion

No tool is perfect for every situation, and abandoning Redux entirely is not recommended. Redux is great, but it comes with creating additional boilerplate code. This lengthened the deadline and left us with more code to maintain.

Local state is appropriate on some components, and can be easily refactored with Redux if complexity changes.

While MobX and Realm are not designed as state containers, they can easily manage most data. It is highly recommended to try out these two libraries to see if they are appropriate for your project.