Translator: Will the world be all right

The original link

Mobx React – Best practices

In this article, I want to show you common best practices for using React with MOBx. I’ll present them as rules. So whenever you encounter a particular problem, try to solve it while following these rules.

This article requires a basic understanding of Store in Mobx. If not, please read this first

Need a quick start? I created a startup project that implements the recommended practices. github.com/danielbisch…

These stores represent UI state

Keep in mind that Store represents the UI state of your application. This means that when you save the state of store to a file, close the program and restart it with the load state, and you will have the same program and see the same content as you saw before you closed the program. Store is not a “local database”. They also contain information about which buttons are visible, disabled, the current text of the input file, and so on.

Separate your REST requests from the Store

Do not call your REST interface from within the store. This makes them difficult to test. Instead, you put these REST calls into additional classes and pass these instances to each store using the store constructor. When you write tests, you can easily forge these API calls and pass the forged API instances to each store.

Keep your business logic in the Store

Do not write business logic in components. When you write business logic in a component, you don’t have a chance to reuse it, and your business logic is spread across many components, making it difficult to refactor or reuse code. Write the business logic using the methods in store and invoke those methods from components.

Do not create a global Store instance.

Do not create a global Store instance. You cannot write any reasonable and reliable tests for components. Instead, use a Provider to inject your store into your component props. You can then easily emulate these stores in your tests.

Only store is allowed to change its properties

Do not change store properties directly in the component. Only stores are allowed to change their own properties. Always call methods from store to change store properties. Otherwise, your application state (stores= application state) will update from anywhere and you are slowly losing control. This makes debugging very difficult.

Always annotate each component with @observer

Each component annotated as @Observer allows each component to be updated in store Prop changes. Otherwise, the parent component annotated with @Component needs to be rerendered to update its children. Therefore, fewer components need to be rerendered.

Using the @ computed

Suppose you want to disable your button when the user has no administrator role and the application is not in “administrator mode.” A single attribute like isAdmin in a store is not enough. You will need the computed properties in store.

You probably don’t need the React Router

You probably don’t need the React Router. As I said before, you want your Store to represent the state of your application. When using the React Router to handle some application state, you don’t want your Store to represent the application state. Therefore, save the currently displayed view in the properties of one of your stores. And then you have a component that just renders what the property says.

Try to support controlled components rather than uncontrolled ones

Always try to build controlled components. This makes testing components and the overall complexity of components easy to deal with.