The Problems With Redux: Can React, MobX, and Realm Save Us?

First off, I don't hate Redux. It was made by very smart people to ease the problem of managing state inside single page apps. And it does solve it. You can use Redux to break state down from the high level right down to what each component needs to know about.

In this article I wanted to share some of our experiences creating mobile apps for our clients. At Quantum Mob, our typical webapps are made on React and our mobile stack is built with React Native. If you aren't familiar with React Native, it allows a single code base (for the most part) between Android / iOS and makes it a lot easier to reuse code from a web version of your product because it's quite similar to regular ol' React.

The Problems with Redux

No tool is perfect for every job. Even if you love something, it doesn't hurt to take a sober second look at it. Especially something with a lot of hype around it. Are you using it because it's the cool thing to do or are you using it because it's the right thing? What's cool comes in and out of style, so if it's asking too much of you, the hype just ain't worth it.

Don't take my word for it, Dan Abramov wrote about his baby and tried to give people reason to pause and consider if it is right for your project or not.

If you feel pressured to do things “the Redux way”, it may be a sign that you or your teammates are taking it too seriously. It’s just one of the tools in your toolbox, an experiment gone wild.

-Dan Abramov

With the advent of npm, Node, and a parade of build tools (grunt, gulp, webpack...), there has been an absolute explosion of libraries and frameworks you need to use in each and every project.

Do you have any dates in your project? Why not throw in MomentJs? Do you deal with arrays? Throw in something like lodash or Ramda. What are you dumb? Use a linter for gawdsake! While you're at it, throw a few githooks in. I honestly don't know how you get out of bed in the morning if you aren't using Babel and Axios and a good CSS framework and all that other stuff you flat headed goof. Make sure to compile your transpiled isomorphic app. Even if it's just your Hello World app. Don't embarrass yourself. Perfection or nothing.

Ok, I've got that out of my system... I'm good now. But seriously, there are way too many devs who get caught up with doing everything all the time. Just because the herd is going one way, that shouldn't make it a foregone conclusion.

Problem I: Learning Curve

Redux introduces a few concepts and you're going to need to study them. You're going to need to pour over the docs and go through the tutorials because it isn't as easy as just making calls to save and then later retrieve your data.

Problem II: Configuration

To get up and going with Redux, you need to configure your store, build your reducers and combine them. Then you're going to want to use connect or something and setup your mapStateToProps and mapDispatchToProps in each component you want to interact with the store. If you want to persist the data at all, that'll be more work too.

Problem III: "Best Practices"

From all the boilerplates you'd assume files are free. For each component, you have a file for the Javascript, a file for the style, and one for the JSX. Redux compounds this with action and reducer files and another for bringing it all together. Sure it makes it more 'Reduxy', but what if you just want to save one field? For simple examples, adding something as powerful as Redux is over-engineering.

Alternatives

Local State

One alternative to Redux is to just keep it simple, use the local state of your component. This concept is to keep it as barebones in the beginning and only add redux when you start needing it. Easy right?

Here's a great example from Dan on how to refactor a simple counter to be Reduxy without using Redux. Check out his article, it's well written and he's an authority on the topic.

MobX

MobX is newer than Redux and there's definitely a lot of buzz about it right now. The promise of MobX is that it gives you all the functionality of Redux, but with far less boilerplate. The downside of this is, of course, it's slightly magical. You shouldn't expect the same level of control as Redux.

How does MobX work? Instead of focussing on the nitty-gritty of mutations and reducers, you create the data model you want to store as a class and add an @observable decorator to the fields you want MobX to manage. You can also provide @computed methods to build on top of the core data you're storing.

One other thing to keep in mind is your objects don't have to be normalized like in Redux. That can be good in some cases and bad in others. If, for example, you have a large array you might run into performance issues searching through it to find the value you want. Just something to be cognizant of.

If you wanted to get a quick overview of MobX, this 4-min video comparing it to Redux is a good start.

If you like the sounds of MobX, check out their official 'ten minute intro' or if you want to see a more skeptical viewpoint one developer went over their app as an example.

Realm for React Native

Realm is another new addition to the React world but currently only available on React Native. If you're making mobile apps it's definitely worth a look. Beyond storing and managing your domain data, Realm adds several powerful features like data syncing with your server, offline support, and encryption.

To help understand the rationale for Realm, they've put out a quick real-world example. Mobile apps often perform multiple searches, thus storing data locally to avoids additional calls speeds up the performance and provides an improved user experience.

Think of Realm as a database integrated directly into your app. They're able to deliver enormous speed because the object references you deal with are the same references the database has and it's saved to your local storage, so any changes or searches are not being serialized or sent anywhere.

Conclusion

No tool is perfect for every situation, and I'm not recommending ditching Redux completely. Redux is great but comes along with boilerplate baggage, creating additional code. This extends our deadlines and gives us more code we must maintain.

Using local state on some of your components is perfectly appropriate at times and can easily be refactored to use Redux later on if complexity changes.

While MobX and Realm are not designed as state containers per se, they can easily take much of the burden out of storing the majority of your data. I highly recommend playing with these two to see if they're a good fit for your project.