Mobx React  Лучшие практики

React.js MobX

Если вы не знаете, что такое mobx, прочтитеэта статья

В этой статье я покажу некоторые лучшие практики React с использованием mobx и покажу их один за другим. Когда вы сталкиваетесь с проблемой, вы можете следовать этим правилам, чтобы решить ее.

Эта статья требует, чтобы вы имели общее представление о магазинах mobx, если нет, сначала прочитайте ее.официальная документация.

хранилища представляют состояние пользовательского интерфейса

Всегда помните, что ваши магазины представляют состояние вашего пользовательского интерфейса, а это означает, что когда вы сохраняете свои магазины, даже если вы закрываете веб-страницу, снова открываете ее и загружаете магазины, веб-страница, которую вы получаете, должна быть идентичной. Хотя хранилища не являются ролью локальной базы данных, они по-прежнему хранят некоторое состояние пользовательского интерфейса, например, видна кнопка или нет, содержимое ввода и т. д.

class SearchStore {
  @observable searchText;

  @action
  setSearchText = (searchText) => {
    this.searchText = searchText
  }
}

@observer
class SearchInput extends React.Component {

  handleInputChanged = (event) => {
    const { searchStore } = this.props;
    searchStore.setSearchText(event.target.value);
  }

  render() {
    const { searchStore } = this.props;
    return (
      <input
        value={searchStore.searchText}
        onChange={this.handleInputChanged}
      />
    );
  }
}

Отделяйте запросы REST API от действий магазина.

Не рекомендуется размещать функции, запрошенные REST API, в хранилищах, поскольку код запроса сложно протестировать. Можно попробовать поместить эти функции запроса в класс, поставить код этого класса вместе с магазином, и при создании магазина этот класс создастся соответственно. Затем, когда вы тестируете, вы также можете элегантно имитировать данные из этих классов.

class TodoApi {

  fetchTodos = () => request.get('/todos')
}

class TodoStore {

  @observable todos = [];

  constructor(todoApi) {
    this.todoApi = todoApi;
  }

  fetchTodos = async () => {
    const todos = await this.todoApi.fetchTodos();

    runInAction(() => {
      this.todos = todos;
    });
  }
}

// 在你的主要函数里面
const todoApi = new TodoApi();
const todoStore = new TodoStore(todoApi);

Разместите свою бизнес-логику в магазинах

Старайтесь не писать бизнес-логику в своих компонентах. Когда вы пишете бизнес-логику в компонентах, у вас нет возможности своевременно обнаруживать ошибки, потому что ваша бизнес-логика разбросана по различным компонентам, что затрудняет определение того, какой код связан с поведением этой ошибки. Лучше всего поместить бизнес-логику в метод магазинов и вызывать ее из компонента.

Избегайте использования экземпляра глобального хранилища

Старайтесь избегать использования экземпляра глобального хранилища, так как это затруднит написание последовательных и надежных тестов компонентов. Вместо этого вы можете использовать Provider для внедрения вашего магазина в реквизиты вашего экземпляра компонента. Таким образом, вы можете легко имитировать эти магазины для тестирования.

const searchStore = new SearchStore();

const app = (
  <Provider searchStore={searchStore}>
    <SearchInput />
  </Provider>
);

ReactDom.render(app, container);

mobxjs/mobx-react

Изменения атрибутов разрешены только в магазине

Пожалуйста, не манипулируйте напрямую значением атрибута хранилища в компоненте. Потому что только хранилище может изменять свои свойства. Если вы хотите изменить свойство, используйте соответствующий метод хранения. В противном случае ваши изменения свойств будут разбросаны повсюду и выйдут из-под контроля, что очень сложно отладить.

Всегда не забывайте объявлять в компоненте@observer

Используйте @observer для объявления каждого компонента, чтобы обновить состояние компонента. В противном случае во вложенном компоненте, если дочерний компонент не объявлен, каждое обновление состояния включает повторную визуализацию уровня родительского компонента. когда вы использовали@observer, количество повторно отображаемых компонентов значительно сокращается.

использовать@computed

Как и в примере кода ниже, используйте@computedproperties для обработки некоторой логики, включающей несколько свойств. использовать@computedЭто может уменьшить частоту появления такой бизнес-логики суждения в компоненте.

class ApplicationStore {

  @observable loggedInUser;

  @observable isInAdminMode;

  @computed isAdminButtonEnabled = () => {
    return this.loggedInUser.role === 'admin' && this.isInAdminMode;
  }
}

Вам не нужен реагирующий маршрутизатор для управления состоянием

Вам не нужно использовать реагирующий маршрутизатор для управления состоянием. Как я уже говорил ранее, ваш магазин представляет состояние вашего приложения. Когда вы позволяете маршрутизатору управлять частью состояния приложения, эта часть состояния отделяется от хранилища. Поэтому попробуйте использовать хранилище для хранения всего состояния пользовательского интерфейса, чтобы свойства хранилища соответствовали тому, что получает ваш интерфейс.

Склонны писать управляемые компоненты

Напишите больше управляемых компонентов, что значительно уменьшит сложность ваших тестов и упростит управление вашими компонентами.

Формы – Реагировать

автор:Daniel Bischoff

оригинал:Mobx React — лучшие практики

Перевод: Доминик Мин

Категории