что-то в ngrx (шаблон избыточности), чем я до сих пор не получаю для больших приложений

Question

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

Теперь я портирую / перепроектирую настольное приложение с примерно 50 формами, все сложные, все полностью функциональные, "умные". Мой подход в последние пару лет заключался в том, чтобы просто тесно взаимодействовать с API остального бэкэнда для извлечения, вставки или обновления данных по мере необходимости, и все работает нормально.

Затем я наткнулся на ngrx и точно понимаю, как он работает,что он делает и почему это хорошо для «реактивного» приложения.

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

Так почему так важно управлять локальным «магазином», когда большая часть моих данных нестабильна? Я понимаю, почему это было бы полезно для глобальных данных приложения, таких как профиль пользователя или общее состояние пользовательского интерфейса, но для самих основных данных? Я не понимаюВы запрашиваете данные, вставляете эти данные в форму, они обрабатываются пользователем и отправляются обратно на сервер. Эти данные больше не нужны, и если они вам нужны, вы запрашиваете их снова, поскольку они могли бы изменить свое состояние с момента последнего взаимодействия с ним.

Я не понимаю, насколькоесли это состояние столь нестабильно, придется обращаться в локальный магазин и весь шаблон.

Говорят, что обнаружение изменений не масштабируется, но я создал несколько действительно больших веб-приложений с простым шаблоном http-сервисаи он работает просто отлично, потому что большая часть дерева компонентов в любом случае уничтожается, когда вы переходите в другое место в приложении, а любые предыдущие подписки становятся бесполезными. Даже с большими громоздкими формами, никогда не бывает такой большой проблемой внутренняя работа формы, как требование внешней «помощи» от магазина. На мой взгляд, «состояние» формы является проблемой этой формы только в этот момент. Поддерживать ли дерево компонентов в синхронизации? никогда не было проблем с этим раньше ... даже для сложных деревьев с большим количеством общих данных, мастер детализации в конечном итоге представляет собой плоский шаблон, если все данные есть.

Для других компонентов, таких как сетки, диаграммы, доклад и т. д., то же самое относится и к. Они получают данные, которые им нужны, а затем "пух" ушли.

Итак, теперь вы видите мое мышление. Я пытаюсь изменить это на что-то лучшее. Почему я пропускаю шаблон редукса?

Answer 1

У меня есть немного опыта здесь! Это все субъективно, поэтому то, что я сделал, может вас не устроить. Моя система - сложная система, которая звучит так же, как и у вас. Сначала я боролся с теми же вопросами: «зачем строить сложную логику на переднем и заднем концах» и «зачем беспокоиться о том, чтобы держать вещи в состоянии».

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

На заднем конце я использую шаблон CQRS вместо традиционного REST API. Как правило, можно предложить повторно реализовать команды / запросы, чтобы «уменьшить» изменения состояния, однако я выбрал другой подход. Я не хочу просто отправлять большой граф объектов обратно на сервер и вставлять его вслепую, и я не хочу повторно реализовывать логику на клиенте и сервере.

Мой базовый "сценарий использования"жизненный цикл выглядит примерно так:

1. Загрузка списка данных (ограниченный размер, не все атрибуты).
2. Пользователь выбирает элемент из списка
3. Клиентские запросы«полный» объект / представление / dto с сервера
4. Клиент сохраняет ответ в состоянии объекта объекта
5. Пользователь начинает изменять данные
6. Эти изменения сохраняются как изменения "в процессе" вдругая часть государства. Теперь система отвечает на данные в части «в процессе»
7. Если с сервера поступает другое изменение, она не перезаписывает данные «в процессе», но заменяет то, что находится в объекте. состояние объекта.
8. При необходимости пользовательский интерфейс показывает, что базовые данные изменились / отличаются от того, что пользователь ввел / что угодно.
9. Пользователь нажимает кнопку «выполнить действие» или иным образом вызываеткоманда для отправки на сервер
10. сервер выполняет команду. Любые ошибки возвращаются, или в случае успеха
11. сервер уведомляет клиента об успешном изменении, клиент очищает информацию «в процессе»
12. сервер уведомляет клиента о том, что Entity X обновлен, клиент повторно запрашиваетобъект X и переводит его в состояние объекта объекта. Это уведомление отправляется всем подключенным клиентам, поэтому все они могут вести себя соответствующим образом.