Как спроектировать масштабируемую архитектуру React Mobx приложения?
Подскажите пожалуйста какие патерны применять для проектирования React Mobx приложения. Есть ли какие либо юзкейсы от крупных компаний, которые применяют данный стек в сложном продакшене? На руках имеется приложение с довольно таки обширным функционалом, где все данные тем или иным образом взаимодействуют между собой, и со временем я начинаю понимать, что чем больше кода появляется тем больше я путаюсь во всех этих связях между сущностями и кто откуда какие методы тягает. Как правильно организовывать эту кодовую базу, чтобы через полгода вернувшись на проект не приходилось распутывать клубок?
Модульная структура позволяет тащить крупные проекты, и чёткая иерархия зависимостей между ними. Также ооп и интерфейсы на все на свете. Отсутствие интерфейсов и модульной структуры ведут к погибели. А какой стек неважно, хоть jquery. Применительно к компонентному подходу, есть только одна хитрость, ui кит должен быть в таком виде что его можно в любой момент в npm засунуть, да и по идее каждый модуль тоже, но с модулями это малодостижимо.
Использую Typescript покрывая все входящие параметры методов и пропсы интерфейсами. Есть корневой модуль который инициализирует в себе инстансы других модулей. Проблема в том что из за специфичного функционала приходится дергать из module1.method1 -> module2.method2. И когда таких связей становится много, то начинаю путаться. К примеру в одном модуле обрабатываются клиентские события для отрисовки svg объектов на плане, и когда он будет отрисован приходится дергать методы из других мест, например для добавления объекта в общий список сущностей и отправки в БД. Мне кажется что это создает лишнюю связанность и модули перестают быть гибкими. Как избавиться от этой проблемы?
Дмитрий Тиркай, вынести на уровень выше. Создать базовый компонент и от него наследоваться. Инжектить сервис с логикой в компонент и вызывать сервис. Можно кидать евенты, сервис подписывается, что то делает и кидает евент с результатом, кто подписан получает и что то делает. Вариантов много в общем в зависимости от ситуации.
И компонент это не модуль. А типы это не интерфейсы, для объектов это тупо структура. У тебя может быть 10 сервисов, но у них один интерфейс, получить данные в таком то формате, я об этом.
Простой
