Table of contents:
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.
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
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"
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?
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.
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.
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.
Receive summaries directly in your inbox.