Иерархическое внедрение зависимостей в React и MobX State Tree в качестве доменной модели

[yallie]

Правильно ли я понял, что при использовании react-ioc компоненты-классы всегда требуют InjectorContext, и собственный static contextType в компоненте уже использовать не получится?

Еще не очень понятен момент регистрации пар [<Интерфейс>, <Реализация>]. Что такое в данном случае интерфейс? TypeScript-интерфейсы ведь не существуют в рантайме, это артефакт времени компиляции. Или тут интерфейс это просто какой-то произвольный объект-маркер?

Спасибо, что нашли время написать статью :)

[ogregor]

На базе этой библиотеки строим приложение для крупного Российского заказчика. Лучшей архитектуры я еще не видел для связки React+MobX+MST. Если сотрудник Яндекса как то сказал, что при переходе на MobX c Redux они сэкономили порядка 3х, то здесь по отношению к MobX еще ее менее 2х, все из за того что DI в корне меняет способ передачи контекста (пропсов). Если раньше мы писали кучи интерфейсов для пропсов, связывали их с другими и прокидывали по всему дереву компонентов, то сейчас мы имеем внедрение зависимостей глобальными сервисами и локальными вьюхами. Теперь пропсы летят исключительно в какие то примитивы типа кнопок и селектов, над всем остальным DI

[ogregor]

отличная библиотека, повидал много занимательных реализаций управления реактивным стейтом в приложениях. Да она не снижает уровень зацепления сервисов, и с ее помощью легко организовать свалку стейтов. Но она дает удобную реализацию. Хотя в целом mobx отлично и так работает без необходимости обвязывать его всякими useState или useMemo или более высокоуровневыми прослойками по типу этой библиотеки. Я стараюсь следовать принципу KISS и поэтому легкое лучше тяжелого...