Опыт использования MobX в большом приложении

возникают трудности с асинхронностью

import { configure } from 'mobx';

// Configure MobX to auto batch all sync mutations without using action/runInAction
setTimeout(() => {
    configure({
        reactionScheduler: (f) => {
            setTimeout(f, 1);
        },
    });
}, 1);

Батчит всё по умолчанию и полностью отпадает нужна в action и runInAction.

codesandbox.io/s/zen-surf-g9r9t?file=/src/App.tsx

Посмотрите код, посмотрите консоль, по нажимаете на кнопочку и снова посмотрите в консоль. После этого раскомментируйте конфигурацию реакций.

Пример с visible является анти-паттерном, так делать очень не рекомендуется.
Loader компоненту должно быть всё равно, что там в модели. Его задача — показать индикатор активности. То же самое для AudioComponent.

Вместо

function Player({ model }) {
   return (
       <div>
           <Loader visible={model.isLoading} />
           <AudioComponent visible={!model.hasAudio && !model.hasErrors} />
       </div>
   );
}

Должно быть

function Player({ model }) {
   return (
       <div>
           {model.isLoading && <Loader />}
           {!model.hasAudio && !model.hasErrors && <AudioComponent />}
       </div>
   );
}

По поводу useMemo/useCallback. Их нужно использовать в исключительных случаях, например, когда создание объекта/функции является ресурсоёмким. Больше по теме: kentcdodds.com/blog/usememo-and-usecallback

Читая статью я совсем не понял, что именно смущает автора в том, что <Player/> ререндерится всякий раз когда меняются поля в модели. Он ведь от них напрямую и зависит. Это явно прописано в его коде. Так оно и должно быть. Никакой проблемы в этом нет.

В то же время вынос этих computed полей в VM (раз уж VM есть), дав им человеко-читаемые имена, это нормальное архитектурное решение. Но едва ли это имеет существенное значение в вопросах производительности. Тут скорее разделение компоненты на VM и V. Полагаю в мире MobX это стандартная практика.

const onClick = useCallback(() => {
  model.doSomething();
}, []);

тут надо бы [model]. Возможно model и статичен, но как минимум, глядя на код, это не очень очевидно :)

Спасибо, что поделились своим опытом. Проблема inject в том, что его нельзя типизировать без костылей, примеры костылей описаны в этой статье. С хуками компонент Player может выглядеть так, у него нет проблем с типизацией:

function Player() {
  const { model } = useStore();
  return (
    <div>
      <Loader visible={model.isLoading} />
      <AudioComponent visible={!model.hasAudio && !model.hasErrors} />
    </div>
  );
}

export default observer(Player)

зачем вы используете inject когда рекомендуется использовать react.context?

Warning: It is recommended to use React.createContext instead! It provides generally the same functionality, and Provider / inject is mostly around for legacy reasons

Статья популяризует MobX, что не может не радовать, это отличный инструмент, на мой взгляд. Хотя описаны довольно простые сценарии, уверен, этот опыт пригодится разработчикам.

Из недостатков вижу следующее:

1. "@action.bound… Не используйте его, если внутри коллбека нет изменения наблюдаемых полей" — тут сразу ряд вопросов.
— Подразумевает ли это, что @action использовать в подобном случае можно?
— Чем мешает использование @action или @action.bound на методах, не изменяющих параметры стора?
— Чем @action.bound такой особенный?

Вот моя версия ответов.
Если параметры стора данным методом не изменяются — то лучше и не использовать на них эти декораторы (@action или @action.bound), так как они навешивают довольно большое количество логики и будут зазря отъедать процессорное время. Но в большинстве случаев это означает, что данный метод — не часть экосистемы MobX store и может быть вынесен как отдельная функция в утилиты.
Различие между @action.bound и @action минимальное, первый отличается лишь биндингом стора. Смотрим реализацию. Сокращенно:

action = createAction(fn.name, fn)
boundAction = createAction(fn.name, fn.bind(target))

Таким образом, это по факту сокращенная форма классического способа биндинга контекста в классах (пятый стандартный способ в дополнение к четырем из статьи):

class Store {
  constructor() { 
    this.myMethod = this.myMethod.bind(this) 
  }
  
  @action myMethod()
}

Так что ничем @action.bound не особенный, и подходит для всех методов стора в экосистеме MobX, и удобнее эти декораторы навешивать автоматически, если придерживаться паттерна actions-inside-classes. Например, таким декоратором.

2. Конвертация кода в другую структуру (из промисов в генераторы) — сомнительное решение. Вопрос недоверия к преобразованному коду в целом уже не возникает, за последний год я не сталкивался с тем, что babel при трансформации создает нерабочий или не так как нужно работающий код, хотя раньше такие случаи не были редкостью. Но вопрос кроссбраузерности стоит. caniuse.com/#feat=es6-generators говорит, что некоторым проектам с широкой поддержкой браузеров такой вариант не подойдет, так как генераторы используют новые синтаксические конструкции, не поддающиеся полифиллингу.
Я бы однозначно выбрал «придется выносить функцию обратного вызова в отдельный метод», подавив в себе желание «иметь возможность передавать анонимную функцию». Получив анонимный стектрейс… Нет, не замечал за собой такого желания)

3. По поводу ререндеринга всего компонента, когда меняются нужные только одному из дочерних элементов параметры, могу предложить такую схему в данном случае (там кстати ошибочка в коде — константа называется то PlayerComp, то AudioComponent):

const AudioComponent = withVisible({
  Component: PlayerComponent,
  condition: state => !state.hasAudio && !state.hasErrors
});

function Player({ model }) {
  return <AudioComponent conditionState={model} />;
}

function withVisible({ Component, condition }) {
  function Visible({ conditionState, ...otherProps }) {
    return !condition(conditionState) ? null : <Component {...otherProps} />;
  }

  return observer(Visible);
}

Тут нужно обратить внимание на то, что так как в этот декоратор передается observable-объект, то нужно добавить observer(Visible) для того, чтобы MobX reaction связал изменения в нем с необходимостью заререндерить этот Visible HOC. Код не проверял, но логических ошибок не вижу)

Другой вариант — передавать <AudioComponent visible="model.showAudio" /> строкой либо годящимся для TS прокси с конвертацией в строку <AudioComponent visible={proxy(model).showAudio.toString()} />, а в декораторе уже подключать соответствующий стор исходя из этой строки и осуществлять MobX observed-наблюдение. Вариант, кстати, годный, но в случае со строками нужна внимательность — при рефакторинге названий параметров подсказок изменить строку не будет, а в случае с линзой получается довольно многословно и нельзя переиспользовать один прокси несколько раз, нужно пересоздавать. Так что недостатки есть, но это в любом случае лучше, чем ререндеры или ручной SCU.

***

Еще, конечно, показалось странным, что целый раздел статьи и столько обсуждений посвятили вопросу, который задается на собеседованиях юниорам из типа — что выведет в консоль данный код, почему, и сколькими методами можно исправить на ожидаемое поведение:

const obj = { method() { console.log(this) } }
obj.method();
const fn = obj.method;
fn();

А в целом — палец вверх за статью!