Shulou(Shulou.com)06/01 Report--

This article focuses on "how to turn on the Time-Travelling engine for MobX". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to start the Time-Travelling engine for MobX.

Preface

Students who know mobx-state-tree should know that as the official state modeling library provided by MobX, MST provides many useful features such as time travel, hot reload, and redux-devtools support. But the problem with MST is that it is too opinioned, and you have to accept their whole set of values (just like redux) before using them.

Let's first take a brief look at how Model is defined in MST:

Import {types} from "mobx-state-tree"

Const Todo = types.model ("Todo", {

Title: types.string

Done: false

}) .actions (self = > ({

Toggle () {

Self.done =! self.done

}

}))

Const Store = types.model ("Store", {

Todos: types.array (Todo)

})

To be honest, the first time I saw this code, I rejected it, it was too subjective, and most importantly, it was counterintuitive. Intuitively we use MobX to define that the model should be in such a pose:

Import {observable, action} from 'mobx'

Class Todo {

Title: string

@ observable done = false

@ action

Toggle () {

This.done =! this.done

}

}

Class Store {

Todos: Todo []

}

Defining Model in the class-based way is obviously more intuitive and purer for developers, while the "subjective" approach of MST is counterintuitive and unfriendly to the maintainability of the project (the class-based method can be understood by anyone who knows the most basic OOP). But correspondingly, the capabilities provided by MST, such as time travel, are really attractive, so is there a way to write MobX comfortably in a conventional way while enjoying the same features as MST?

Compared to the serialization-unfriendly paradigm of MobX's multi-store and class-method-based action, Redux is obviously much easier to support features like time travel/action replay (but the corresponding application code is also much more cumbersome). But as long as we solve two problems, the problem of time travel/action replay support for MobX will be easily solved:

Collect all the store of the application, do reactive activation on it, and manually serialize (snapshot) when changing. Complete the store-> reactive store collection-> snapshot (json) process.

Identify and map the collected store instances and all kinds of mutation (action). Complete the reverse process of snapshot (json)-> class-based store.

Mmlpx gives corresponding solutions to these two problems:

DI + reactive container + snapshot (collect store and generate serialized snapshot in response to store changes)

Ts-plugin-mmlpx + hydrate (marks store and aciton and injects serialized data into store instances with status)

Let's take a look at how mmlpx gives these two solutions based on snapshot.

The basic capabilities required by Snapshot

As mentioned above, to provide snapshot capabilities for the state of applications under MobX, we need to address the following issues:

Collect all the store of the application

MobX itself is a weak proposition in application organization, which does not limit how applications organize state store, follow a single store (such as redux) or multi-store paradigm, but because MobX itself is OOP-oriented, in practice we usually use the code of conduct in MVVM pattern to define our Domain Model and UI-Related Model (how to distinguish these two types of models can be seen in MVVM-related articles or MobX official best practices, which will not be discussed here). This causes us to follow the multi-store paradigm by default when using MobX. So what if we want to manage all the store of the application?

In the OOP worldview, to manage all instances of class, we naturally need a centralized storage container, which is often easily associated with IOC Container (inversion of Control). DI (dependency injection), as the most common IOC implementation, is a good alternative to the previous manual instantiation of MobX Store. With DI, the way we quote a store looks like this:

Import {inject} from 'mmlpx'

Import UserStore from'. / UserStore'

Class AppViewModel {

@ inject () userStore: UserStore

LoadUsers () {

This.userStore.loadUser ()

}

}

After that, we can easily get all the store instances instantiated by dependency injection from the IOC container. In this way, the problem of collecting and applying all store is solved.

For more DI usage, see mmlpx di system here.

Respond to state changes for all store

After getting all the store instances, the next step is how to listen for changes in the states defined in these store.

If all the store in the application has been completed after the initialization of the application, it will be relatively easy for us to monitor the changes of the entire application. But usually in a DI system, this instantiation action is lazy, that is, only when a Store is actually used will it be instantiated and its state will be initialized. This means that the IOC container should be converted to reactive from the moment we turn on the snapshot feature, so that we can automatically bind and listen to the states defined in the newly managed store and store.

At this time, we can get the current IOC Container in onSnapshot, dump all the currently collected stores, then build a new Container based on MobX ObservableMap, load into all previous store, and finally recursively traverse the data defined in store while using reaction as track dependencies, so that we can respond to the state changes of the container itself (Store join / destroy) and store. If we manually serialize the current application status when the change triggers reaction, we can get a snapshot of the current application.

The specific implementation can be seen here: mmlpx onSnapshot

Wake up applications from Snapshot

Usually, after we get the snapshot data of the application, we persist it to ensure that the application can directly return to the exit state ── on the next entry, or we need to implement a common redo/undo function.

This is relatively easy to do in the Redux system because the state itself is plain object and serialization-friendly at the definition stage. But this does not mean that wake-up applications from Snapshot cannot be achieved in a serialization-unfriendly MobX system.

To successfully resume from snapshot, we have to meet these two conditions:

Add a unique identification to each Store

If we want the serialized snapshot data to be successfully restored to their respective Store, we must give each Store a unique identity so that the IOC container can associate each layer of data with its original Store through this id.

Under the mmlpx scenario, we can mark the applied global state and local state with @ Store and @ ViewModel decorators, and give the corresponding model class an id:

@ Store ('UserStore')

Class UserStore {}

But obviously, naming Store manually is stupid and error-prone, and you have to make sure that their namespaces don't overlap (that's exactly what redux did).

Fortunately, this thing has ts-plugin-mmlpx to help you do it automatically. When we define Store, we only need to write this:

@ Store

Class UserStore {}

After being converted by the plug-in, it becomes:

@ Store ('UserStore.ts/UserStore')

Class UserStore {}

The uniqueness of the Store namespace is usually ensured through the combination of fileName and className. For more information about the use of plug-ins, please follow the ts-plugin-mmlpx project home page.

Hyration

The reverse process of activating an applied reactive system from a serialized snapshot state to dynamic recovery is very similar to hydration in SSR. In fact, this is also the most difficult step to implement Time Travelling in MobX. Unlike Flux-inspired libraries such as redux and vuex, states in MobX are usually defined based on a congested model like class, and after dehydration and rehydration of the model, we must also ensure that behavior definitions (action method) that cannot be serialized are still correctly bound to the model context. Just the rebinding behavior is not over, we also have to make sure that the mobx modification of the data after deserialization is consistent with the original. For example, I used to decorate with data with special behavior such as observable.ref, observable.shallow and ObservableMap. After reinjection, we must be able to keep the original features unchanged, especially for non-object Array non-serialized data such as ObservableMap, we all have to find ways to reactivate them and restore them to their original state.

Fortunately, the cornerstone of our entire solution is the DI system, which gives us the possibility of "tampering" when the caller asks for a dependency. We only need to determine whether the get is populated from serialized data when relying on hydrate, that is, the Store instance stored in the IOC container is not an instance of the original type, and then the hydrate action is enabled, and then the hydration object after water injection is returned to the caller. The activation process is also simple, because there is a store Constructor in our inject context, so we just need to reinitialize a new blank store instance and populate it with serialization data. Fortunately, there are only three data types in MobX, object, array and map. We only need to simply deal with different types to complete hydrate:

If (! (instance instanceof Host)) {

Const real: any = new Host (... args)

/ / awake the reactive system of the model

Object.keys (instance) .forEach ((key: string) = > {

If (real [key] instanceof ObservableMap) {

Const {name, enhancer} = real [key]

RunInAction (() = > real [key] = new ObservableMap ((instance as any) [key], enhancer, name))

} else {

RunInAction (() = > real [key] = (instance as any) [key]))

}

});

Return real as T

}

The complete code of hydrate can be seen here: hyrate

Application scenario

Compared with the snapshot capability of MST (MST can only take a snapshot of a Store, but not the entire snapshot), mmlpx-based solutions become easier to implement Snapshot-based functions:

Time Travelling

The Time Travelling function has two application scenarios in the actual development, one is redo/undo, the other is the application replay function provided by redux-devtools.

After mmlpx is installed, it becomes very easy for MobX to implement redo/undo. Instead of posting the code (in fact, onSnapshot and applySnapshot api), interested students can check mmlpx todomvc demo (that is, the gif effect posted at the beginning of the article) and the mmlpx project home page.

Functions like redux-devtools are relatively difficult to implement (and actually very simple), because if we want to replay every action, the premise is that each action has a unique identity. The approach in redux is to manually write action_types with different namespaces, which is too tedious (refer to what is the fatal flaw in the Redux data flow management architecture and how will it be improved in the future?). Fortunately, we have ts-plugin-mmlpx that can help us name action automatically (the principle is the same as naming store automatically). After solving this problem, we only need to record each action at the same time in onSnapshot, and we can easily use the functions of redux-devtool in mobx.

SSR

We know that when React or Vue do SSR, they pass prefetched data to the client by mounting global variables on window, but usually the official examples are based on Redux or Vuex. Before that, MobX still has something to solve if it wants to achieve client activation. Now with the help of mmlpx, we only need to use the passed prefetching data to apply the snapshot on the client side before the application starts, and the client state activation can be realized based on MobX:

Import {applySnapshot} from 'mmlpx'

If (window.__PRELOADED_STATE__) {

ApplySnapshot (window.__PRELOADED_STATE__)

}

Application of crash monitoring

This can be achieved as long as the state management library used has the ability to take a complete snapshot of the application at any time and activate the state relationship from the snapshot data. That is, press the shutter when checking the application of crash, upload the snapshot data to the cloud, and finally restore the scene through the snapshot data on the cloud platform. If the snapshot data we upload also includes the user's previous operation stack, then it is not a problem to replay the user's operations on the monitoring platform.

At this point, I believe you have a deeper understanding of "how to turn on the Time-Travelling engine for MobX". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.