|
| 1 | +--- |
| 2 | +id: MST-integration |
| 3 | +title: Integrating with MobX State Tree |
| 4 | +sidebar_label: MobX State Tree integration |
| 5 | +--- |
| 6 | + |
| 7 | +> TODO: This guide is incomplete. Please help improve this by sending pull requests. |
| 8 | +
|
| 9 | +This guide explores possible way to use React Navigation in a React Native project that uses [MobX State Tree](https://github.com/mobxjs/mobx-state-tree)(MST) for state management. The guide is accompanied by a [sample app](https://github.com/vonovak/react-navigation-mst-demo). Parts of the guide may be relevant also for users of [MobX](https://github.com/mobxjs/mobx) but please be aware of the fact that MobX does not come with a built-in solution for (de)serializing its state. |
| 10 | + |
| 11 | +> Please note that in this guide, Mobx State Tree is not used to manage the navigation state itself - just the navigation params! |
| 12 | +
|
| 13 | +## Overview |
| 14 | + |
| 15 | +Our goal with this guide is to use MST with React Navigation and achieve optimal developer experience. In the scope of this guide, this means allowing us to do a full JS reload and be brought back to the state before the reload happened. |
| 16 | + |
| 17 | +We will do this by persisting the [navigation state](navigation-state.md) using the React Navigation's [built-in mechanism](state-persistence.md). We also need to persist the app state and navigation params - that way, when you're working on a screen in your app and do a full JS reload, you will be brought back to the same screen, with the same data in it. |
| 18 | + |
| 19 | +## Guide |
| 20 | + |
| 21 | +First, start by creating initial navigation structure and React components. When you're done with that, continue with modelling your state in MST. If you want to learn more about this, check out the [egghead.io course](https://egghead.io/lessons/react-describe-your-application-domain-using-mobx-state-tree-mst-models). |
| 22 | + |
| 23 | +At this point, you're probably wondering how to connect your MST objects with the components. The answer is in the [mobx-react package](https://github.com/mobxjs/mobx-react) that contains React bindings for MobX (they also work for MST). You will likely be using the `Provider` component and the `inject` and `observer` functions. |
| 24 | + |
| 25 | +Use `Provider` to wrap what you return from your root component's render method: |
| 26 | + |
| 27 | +```js |
| 28 | +<Provider myObject={this.myObject}> |
| 29 | + <NavigationContainer>{/* Screen configuration */}</NavigationContainer> |
| 30 | +</Provider> |
| 31 | +``` |
| 32 | + |
| 33 | +this will allow you to access `myObject` from any React component in the application through the `inject` function which can be quite useful. |
| 34 | + |
| 35 | +Use `observer` function to wrap all components that render observable data. This will make sure the components re-render once the data they render changes. |
| 36 | + |
| 37 | +### Navigation params |
| 38 | + |
| 39 | +Screens in your application often depend on params. React Navigation allows you to [send params](params.md) from one screen to another. These params are stored in the navigation state. However, in order to persist the navigation state, it needs to be serializable. This requirement does not play well with MST, because the MST objects are complex objects and React Navigation doesn't know how to (de)serialize them. In this guide, we will work around this by storing the navigation params ourselves. |
| 40 | + |
| 41 | +This means that rather than sending the params from one screen to another (eg. with `props.navigation.navigate('MyScreen', { complexMSTObject })`) we will store the params to a navigation store, then navigate without sending any params, and on the target screen, we'll pick the params up from the navigation store. |
| 42 | + |
| 43 | +To give an example, the navigation store may look similar to this: |
| 44 | + |
| 45 | +```js |
| 46 | +import { types, onSnapshot, getRoot } from 'mobx-state-tree'; |
| 47 | +import { Product } from '../models/Product'; |
| 48 | +import { User } from '../models/User'; |
| 49 | + |
| 50 | +export const NavigationStore = types |
| 51 | + .model('NavigationStore', { |
| 52 | + productDetailScreenParams: types.map( |
| 53 | + types.model('ProductDetailScreenParams', { |
| 54 | + product: types.optional(types.safeReference(Product)), |
| 55 | + }) |
| 56 | + ), |
| 57 | + userProfileScreenParams: types.model('UserProfileScreenParams', { |
| 58 | + user: types.maybe(types.safeReference(User)), |
| 59 | + }), |
| 60 | + }) |
| 61 | + .actions(self => ({ |
| 62 | + ... |
| 63 | + })); |
| 64 | +``` |
| 65 | + |
| 66 | +Note that `userProfileScreenParams` is a simple model with a `user` entry, while `productDetailScreenParams` is a map of `ProductDetailScreenParams` model. The reason we chose this shape of data is that we only have a single user profile screen in our app which reads its params from `userProfileScreenParams`. `productDetailScreenParams` is a map because the app can have several product screens on a stack. Each screen points to a `Product` instance saved in the map. The keys into the map are the React Navigation [keys](navigation-state.md): think of the `key` as of an identifier of the route. |
| 67 | + |
| 68 | +Your navigation store may also be just one map where for each screen (regardless if it is a product or user profile screen), we store its navigation params. This is the approach taken in the [sample app](https://github.com/vonovak/react-navigation-mst-demo). |
| 69 | + |
| 70 | +## Summary |
| 71 | + |
| 72 | +- you can use React Navigation with MobX State Tree in a React Native app |
| 73 | +- use the `Provider` component and the `inject` and `observer` functions to wire up MobX or MST with React |
| 74 | +- it's possible to persist the entire application state and restore it upon JS reload |
0 commit comments