Когда 'действие' / 'runInAction' действительно необходимо в Mobx реагировать - PullRequest
1 голос
/ 06 апреля 2020

Может кто-нибудь объяснить мне, в чем реальная разница и почему оба примера здесь работают одинаково:

1) Измените состояние наблюдаемого через action / runInAction внутри файла хранилища:

файл colorStore:

@observable
color='red'

@action
setColor(){
  this.color='blue'
}

2) Измените состояние через сам компонент (что считается плохой практикой):

Файл компонента реагирования:

onClick = () => this.props.colorStore.color='blue' //still working...

Ответы [ 2 ]

2 голосов
/ 06 апреля 2020

Mobx action выполняет пакетирование , аналогично тому, как ReactJS группирует несколько изменений.

Когда вы используете обработчик reactjs click, реакция автоматически пакетирует изменения, которые произойдет внутри него, поэтому вы не увидите рендеринг компонента несколько раз, однако, если вы вызовете setColor из какого-то другого события, скажем, после загрузки некоторых данных, и у вас будет несколько вызовов для изменения наблюдаемой внутри setColor, которая вызовет наблюдатель три раза, а компонент будет визуализирован три раза.

Когда вы оберните свою функцию декоратором @action или используете функцию runInAction, будет использовано только последнее значение (green в приведенный ниже код), и компонент будет визуализирован только один раз.

setColor(){
  // this will render three times
  this.color='blue'
  this.color='red'
  this.color='green'
}

пример vanilla mobx, который реагирует только один раз:

import { runInAction, observable, reaction, toJS } from "mobx";

const test = observable({
  name: "sonic",
  nick: "speed demon"
});

// console.log will be called only once with the value "name: 3"
reaction(
  () => toJS(test),
  data => console.log(`name: ${data.name}`)
);

runInAction(() => {
  test.name = "1";
  test.name = "2";
  test.name = "3";
});

представление на codesandbox

Также ознакомьтесь с обсуждением на репозитории github: действительно ли необходимо @action?

0 голосов
/ 06 апреля 2020

Разница больше связана с соглашениями и написанием чистого поддерживаемого кода , чем с поведением программы. Итак:

  1. Вы мутируете и сохраняете данные в компоненте UI . Это не правильно, потому что UI должен только визуализировать данные и обрабатывать, например, действия пользователя, которые затем преобразуются в определенное действие в хранилище данных (в вашем случае обновление цвета). ответственность магазина за управление состоянием этих данных
  2. Все наблюдаемые данные считаются хорошей практикой, если мутировать только в действиях . Почему? Потому что единый источник мутирующих данных ясен - только в действиях и только в слое данных (хранилище). Код менее подвержен ошибкам и нечеткому управлению состоянием, и большое преимущество заключается в том, что вы можете принудительно запретить сборку приложения, если включите режим use strict
...