Models for your Mobx Store-

Think of defining the models as you define a schema in a Mongo database, so that once you define the model you can push new data into the Mobx store using that model.

Using this approach has many benefits:

You will have a single place where you define your Store schema.

You can change the schema according to your own needs.

You can reuse the model you defined for different store variables.

It’s like if you have two kind of users in the app all having the same key-value pairs, you can define them in the same model if you like.

The model is a class wherein each of the class variables can be made as observables if you want Mobx to watch them, eg. you create a model (which is a class) called user , this will have variables such as name, DOB, interests etc.

So (say) inside your Mobx store is an array of users called userList Whenever you create a new user you basically create a new object of the class user . And then you push that new user inside your userList. So the userList array which just observed the child objects now also observes the name, DOB etc.

Problems I faced with Mobx and how to overcome them-

Mobx didn’t re-render the ListView when I changed values in the ListView’s data source.

This is a simple Mobx store. list is an array of objects.

First of all my data source was an array of objects (collection) which were further nested objects. So when I tried to change a value( live ) in the nested object Mobx didn’t re-render. This is because Mobx didn’t observe my array in depth. Had I inserted a new object in the array the list would have re-rendered perfectly.

) in the nested object Mobx didn’t re-render. This is because Mobx didn’t observe my array in depth. Had I inserted a new object in the array the list would have re-rendered perfectly. So what we do is we make a model for each nested object / array and insert that model into our datasource. As you can see in the model code snippet, each variable in the model itself is an @observable. This tells Mobx to observe changes in that particular variable.

So now back to our Mobx store, we add new objects to list as follows:

Models is a very powerful tool as we can tell Mobx what values in an object do we need to observe. So we can optimize our re-rendering. Moreover you might think that having more observables might slow down your app, but it’s actually quite the opposite. In Mobx having more observables is good , more is the observables more the Mobx knows when and how much data has changed.

2. When reading Mobx data (say an array) it shows `undefined`.

I had hard time with this issue. Basically what I mean is when you store any data in the Mobx store, it wraps that data for it’s own purpose. So that data is not plain / JSON data, which means React will not be able to read it.

So every time you read the data from the Mobx store you need to convert it from an observable / wrapped data to plain data.

You can do that using:

const list = toJS(mobxStore.list);

now you can use this array in your React component like this:

Tools to help for simplifying your development:

Use mobx-logger to check what and how Mobx changes your store.

to check what and how Mobx changes your store. Use mobx-react-devtools to track the rendering behaviour and data dependency .Check this comment to see how that works.

to track the rendering behaviour and data dependency .Check this comment to see how that works. Use mobx-persist to store data locally in your app for offline usage.

TIP: Make custom file links in your repo for easy imports.

To make it easy for you to import files when the folder structure is nested too much.

Wouldn’t it be cool if instead of:

import SignUpScreen from '../../storybook/stories/screens/signup';

You could just do:

import SignUpScreen from 'screens/signup';

To do this you need to install babel-plugin-module-resolver package as a dev dependency.

Then in your project’s .babelrc file you can write your custom alias:

Here’s the link to the repo so that you can view it on your own how we do that. I guess the code is pretty self explanatory!