Ну сама интеграция с Реактом (проброс IoC контейнер(ов)) идёт всё-равно через React Context – это низкоуровневый апи, от этого никуда не уйти. Надёжнее – это не в плане, что какой-то там из use'ов отвалится из-за вспышки в верхних слоях атмосферы, а надёжный выбор – не подведёт при усложнении проекта и появлении новых челленджей. Иерархичность, разные виды байндингов/мэппингов, асинхронные подгружаемые зависимости и т.д. Вся эта проблематика обкатана годами на разных платформах и технологиях.
Я, как пользователь и контрибьютор inversify-react, хотел бы сделать акцент на том, что UI вторичен, а DI нужен везде, поэтому и решения типа inversify + интеграция с Реактом выглядят полезнее-надёжнее.
membrumMaZaAa NB! Вот тут Мишель (автор MobX) отмечает, что он как раз by design стремился к синхронному исполнению реакций, так что откладывание на микротаску (и тем более на макротаску) скорее будет усложнять жизнь.
и вот ещё из доки:
reactionScheduler: (f: () => void) => void
Sets a new function that executes all MobX reactions. By default reactionScheduler just runs the f reaction without any other behavior. This can be useful for basic debugging, or slowing down reactions to visualize application updates.
«нужный стор» понятие относительное, относительно контекста использования. Почитайте про концепцию Dependency Injection и, например, про реактовый контекст.
Нет, мы работаем с MobX и InversifyJS для жирной модульной бизнес-логики со сложными графами связанных объектов в своих ограниченных контекстах (модули), а React всё это рендерит, инжектя в себя необходимые вью-модели (сторы) из тех контекстов, которые ему доступны в том или ином поддереве.
А ваш совет подходит для TODO-app на нескольких синглтонах.
а просто будете делать import вашего стора/сторов, то вообще будет сказка
не учите плохому, это фактически тот же самый
MyThing.getInstance()
Для прямого связывания сторов (моделей) есть DI через конструктор (poor man's DI ручками через конструктор),
для связывания UI компонент с ними есть DI или на пропсах, или сырой реактовый контекст, или нормальные IoC абстракции над контекстом (InversifyJS)
Иерархичность – ок, вещь полезная и необходимая. Я правильно понимаю, что ты видишь это bottleneck'ом, и, соответственно, главным аспектом вопроса фронтендового DI?
На случай, если да – сразу спрошу – откуда появляется необходимость делать это прям по дереву компонентов? У нас в проекте (гэмблинг :/) по сути два контейнера – сессионный и конкретной подгружаемой игры – и это вроде хватает.
А в чём мотивация делать IoC именно под React? Ведь это абстрактная штука, не связанная с реактом.
Вот например InversifyJS это просто хороший IoC container, который можно заюзать и с реактом, и без реакта (с чем захочешь, под что напишешь адаптер).
всё так
https://github.com/Kukkimonsuta/inversify-react#provider
Ну сама интеграция с Реактом (проброс IoC контейнер(ов)) идёт всё-равно через React Context – это низкоуровневый апи, от этого никуда не уйти.
Надёжнее – это не в плане, что какой-то там из use'ов отвалится из-за вспышки в верхних слоях атмосферы, а надёжный выбор – не подведёт при усложнении проекта и появлении новых челленджей. Иерархичность, разные виды байндингов/мэппингов, асинхронные подгружаемые зависимости и т.д. Вся эта проблематика обкатана годами на разных платформах и технологиях.
Я, как пользователь и контрибьютор
inversify-react, хотел бы сделать акцент на том, что UI вторичен, а DI нужен везде, поэтому и решения типаinversify+ интеграция с Реактом выглядят полезнее-надёжнее.который непонятно как может взорваться
NB! Вот тут Мишель (автор MobX) отмечает, что он как раз by design стремился к синхронному исполнению реакций, так что откладывание на микротаску (и тем более на макротаску) скорее будет усложнять жизнь.
и вот ещё из доки:
mobx.js.org/refguide/api.html#reactionscheduler-f-void-void
По моим впечатлением, оно уже долгое время является самой мощной и удобной реализацией в мире JS/TS.
Это троллинг?
А ваш совет подходит для TODO-app на нескольких синглтонах.
не учите плохому, это фактически тот же самый
Для прямого связывания сторов (моделей) есть DI через конструктор (poor man's DI ручками через конструктор),
для связывания UI компонент с ними есть DI или на пропсах, или сырой реактовый контекст, или нормальные IoC абстракции над контекстом (InversifyJS)
На случай, если да – сразу спрошу – откуда появляется необходимость делать это прям по дереву компонентов? У нас в проекте (гэмблинг :/) по сути два контейнера – сессионный и конкретной подгружаемой игры – и это вроде хватает.
Вот например InversifyJS это просто хороший IoC container, который можно заюзать и с реактом, и без реакта (с чем захочешь, под что напишешь адаптер).