Мы создали несколько приложений в нашем стартапе. mobx-state-tree(MST) был ранним выбором для замены Redux. Когда я присоединился, в кодовой базе было довольно много кода на TypeScript, MobX и MST. В основном мы работаем над двумя из них. Приложения представляют собой системы управления для настройки конфигураций и отображения диаграмм, а также редактирования графиков. После того, как мы работали над этими приложениями в течение нескольких месяцев, кодовая база стала намного больше.

MST может быть не лучшим инструментом для нашего случая, хотя он все еще мощный. Я чувствую, что есть некоторые болевые точки.

Ошибки проверки типа неясны

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

Неожиданные ошибки в производстве

Ошибки были выброшены несколько раз в процессе производства из-за искаженного кода. Обычно никакой полезной информации не выводится, а только ошибка, связанная с методом initiate. Затем я должен воспроизвести проблему в своем локальном приложении и посмотреть, что я могу найти.

Я разговаривал с коллегой. Оказалось, что нам обоим не нравится, когда MST выдает ошибки в продакшене таким образом. Мы хотим, чтобы приложение работало как можно дольше, даже если структура данных немного изменилась. И не каждое изменение структуры приведет к поломке приложения.

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

У нас есть состояния на уровне компонентов

Поскольку в нашем приложении слишком много типов данных, мы не помещаем все данные в наше хранилище, а вместо этого загружаем их во времяcomponentDidMount и загружаем больше по мере необходимости. Документы для MST просты как файл README, я не вижу нормального решения для таких случаев. Поэтому вместо этого мы использовали MobX для размещения данных внутри компонентов с функцией typecheck из MST в качестве средства проверки схемы.

Это может быть странным вариантом использования, но это то, что нам нужно. Нам нужен гибкий валидатор данных, однако схема json этого не решает. MST предлагает систему типов, похожую на TypeScript, и в нашем случае она оказалась очень удобной. Определения типов могут использоваться компилятором и средой выполнения при проверке структуры данных. Я хотел бы узнать больше об этом и посмотреть, как это улучшит наше приложение.

Вывод

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