Redux vs MobX: Which Is Best for Your Project?

For a lot of JavaScript developers, the biggest complaint with Redux is the amount of boilerplate code needed to implement features. A better alternative is MobX which provides similar functionality but with lesser code to write.

For MobX newbies, take a quick look at this introduction written by MobX's creator. You can also work through this tutorial to gain some practical experience.

The goal of this article is to help JavaScript developers decide which of these two state management solutions are best for their projects. I've migrated this CRUD Redux project to MobX to use as an example in this article. I'll first discuss the pros and cons of using MobX then I'll demonstrate actual code samples from both versions to show the difference.

The code for the projects mentioned in this article can be found on GitHub:

• http://ift.tt/2rSvzBG
• http://ift.tt/2qz1enW

What do Redux and MobX have in Common?

First, let's look at what they both have in common. They:

• Are open-source libraries
• Provide client-side state management
• Support time-travel debugging via redux-devtools-extension
• Are not tied to a specific framework
• Have extensive support for React/React Native frameworks

4 Reasons to use MobX

Let's now look at the main differences between Redux and MobX.

1. Easy to learn and use

For a beginner, you can learn how to use MobX in just 30 minutes. Once you learn the basics, that's it. You don't need to learn anything new. With Redux the basics are easy too. However, once you start building more complex applications you will have to deal with:

• Handling async actions with redux-thunk
• Simplifying your code with redux-saga
• Define selectors to handle computed values etc.

With MobX, all these situations are "magically" taken care of. You don't need additional libraries to handle such situations.

2. Less code to write

To implement a feature in Redux, you need to update at least four artifacts. This includes writing code for reducers, actions, containers and components. This is particularly annoying if you are working on a small project. MobX only requires you to update at least 2 artifacts (i.e. the store and the view component).

3. Full support for object-oriented programming

If you prefer writing object-oriented code, then you will be pleased to know you can use OOP to implement state management logic with MobX. Through the use of decorators such as @observable and @observer, you can easily make your plain JavaScript components and stores reactive. If you prefer functional programming, no problem; that is supported as well. Redux, on the other hand, is heavily geared towards functional programming principles. However, you can use the redux-connect-decorator library if you want a class based approach.

4. Dealing with nested data is easy

In most JavaScript applications, you'll find yourself working with relational or nested data. To be able to use it in a Redux store, you will have to normalize it first. Next, you have to write some more code to manage tracking of references in normalized data.

In MobX, it is recommended to store your data in a denormalized form. MobX can keep track of the relations for you and will automatically re-render changes. By using domain objects to store your data, you can refer directly to other domain objects defined in other stores. In addition, you can use (@)computed decorators and modifiers for observables to easily solve complex data challenges.

3 Reasons not to use MobX

1. Too much freedom

Redux is a framework that provides strict guidelines on how you write state code. This means you can easily write tests and develop maintainable code. MobX is a library and has no rules on how to implement it. The danger with this is that it's very easy to take shortcuts and apply quick fixes which can lead to unmaintainable code.

2. Hard to debug

MobX's internal code "magically" handles a lot of logic to make your application reactive. There's an invisible area where your data passes between the store and your component which makes it difficult to debug when you have a problem. If you change state directly in components, without using @actions, you will have a hard time pinpointing the source of a bug.

3. There could be a better alternative to MobX

In software development, new emerging trends appear all the time. Within a few short years, current software techniques can quickly loose momentum. At the moment, there are several solutions competing with both Redux and Mobx. A few examples are Relay/Apollo & GraphQL, Alt.js and Jumpsuit. Any of these technologies has the potential to become the most popular. If you really want to know which one is best for you, you'll have to try them all.

Continue reading %Redux vs MobX: Which Is Best for Your Project?%

by Michael Wanyoike via SitePoint