Каковы преимущества использования хранилища (ngrx) в angular 2

Ответ 1

Несмотря на то, что ваш вопрос в основном основан на мнениях, я могу дать вам некоторые идеи, почему ngrx - хороший выбор. Несмотря на то, что люди говорят, что неплохо иметь все ваше приложение в одном объекте (Single State Tree). Однако, на мой взгляд, ваше государство будет там независимо. С магазином это всего лишь одно место, а мутации - явные и отслеживаемые, а также забитые и поддерживаемые локально компонентами. Кроме того, вы выбираете определенные свойства из своего магазина в своем приложении, поэтому вы можете выбирать только те данные, которые вам интересны. Если вы затем включите неизменность в своих редукторах, всегда возвращая массив, например, и используя Observables, вы можете использовать ChangeDetectionStrategy OnPush. OnPush дает вам хороший прирост производительности. Давайте взглянем на следующий рисунок из официального Angular docs:

Как вы можете видеть, приложение Angular создается с использованием архитектуры компонентов, что приводит к созданию дерева компонентов. OnPush на компоненте означает, что только если изменяются входные атрибуты, произойдет обнаружение изменения. Например, если Child B - OnPush и Child A - Default, и вы что-то измените внутри Child A, Child B детектор изменений не будет запущен, так как никаких атрибутов ввода не изменилось. Однако, если вы что-то измените внутри Child B, Child A будет перерисовываться, поскольку у него есть детекторы изменений по умолчанию.

Так много о производительности и единственном дереве состояний. Еще одно преимущество магазина заключается в том, что вы можете действительно рассуждать о своих изменениях кода и состояния. Таким образом, реальность большинства приложений Angular 1.x - суп суба. Вот хороший график из сообщения в блоге от Lukas Ruebbelke:

Изображение демонстрирует это довольно хорошо. Еще одна статья от Tero Parviainen рассказывает о том, как он улучшил свои приложения Angular, запретив ng-controller. То, что все относится к супу объема и управлению постоянно меняющимся состоянием, сложно. Мотивация redux гласит следующее здесь:

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

Используя ngrx/store, вы можете обойти эту проблему, потому что вы получите чистый поток данных в своем приложении.

Так как ngrx очень вдохновлен сокращением, я бы сказал, что те же основные принципы применимы:

• Единственный источник истины
• Состояние доступно только для чтения
• Изменения производятся с помощью чистых функций

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

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

Возможность тестирования, как уже упоминалось, @muetzerich, также является преимуществом использования ngrx/store. Редукторы - это чистые функции, и эти функции легко тестировать, потому что они берут ввод и просто возвращают результат и не зависят от свойств вне функции и не имеют побочных эффектов, например. http-звонки и т.д.

Чтобы перейти к нижней строке, я бы сказал, что не нужно использовать ngrx/store для выполнения любой из этих вещей, но вы будете привязаны к ограничениям (три принципа, упомянутые выше), которые обеспечивают общий шаблон и принести приятные выгоды.

На ваши вопросы:

Нужно ли мне несколько магазинов для моего приложения, если у меня есть несколько типов данных (запас, заказ, клиент...)?

Нет, я бы не предлагал использовать несколько магазинов.

Как я могу структурировать (разрабатывать) мое приложение для работы с несколькими типами данных, такими как эти?

Возможно, это сообщение в блогеTero Parviainen поможет вам разобраться, как создать свой магазин. Он объясняет, как создать дерево состояний приложения для примера приложения.

Ответ 2

Хорошее объяснение о преимуществах использования магазина, которое вы можете найти там документация

Централизованное, неизменяемое состояние

Все соответствующее состояние приложения существует в одном месте. Это облегчает отслеживание проблем, поскольку моментальный снимок состояния во время ошибки может обеспечить важную проницательность и облегчить воссоздание проблем. Это также вызывает печально известные проблемы, такие как undo/redo trivial в контексте приложения Store и обеспечивает мощную оснастку.

Производительность

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

Тестируемость

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

Несколько магазинов?

IMO использует одно хранилище и добавляет ваши типы данных в качестве свойств в вашем магазине.

Ответ 3

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

На самом деле легко получить непоправимый беспорядок со службами и компонентами. Если у вас есть каскадные действия, сложные взаимодействия данных и звонки в удаленные места, вы в конечном итоге структурируете сервис, который почти идентичен механизму сохранения действия-восстановления в ngrx. Маленькие чистые функции, наблюдаемые и т.д. Ngrx уже есть, почему бы не использовать его и не получить от мысли и шаблонов, которые он представляет.

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

Образец Angular2 становится проще. Шаблоны с логикой отображения, компоненты как место сбора всех битов и кусков, которые требуется шаблону. Сервисы упрощаются, поскольку они просто делают удаленные вызовы или обрабатывают io для данных из любой точки. Затем действия и редукторы для поддержания и изменения состояния, которые заставляют все остальные части реагировать на новое состояние. Я обнаружил, что с шаблоном компонента/обслуживания либо один начнет становиться большим и сложным, а побочным эффектом его становится чрезвычайно сложно отлаживать. Мои сервисы заканчивались сохранением состояния и выполнением данных io.

Наблюдаемые. Все это наблюдается в rxjs.store, и это является основой для гибкого приложения. Структурирование состояния приложения в качестве наблюдаемого иногда бывает немного тайным или не очень простым, но вычисление его и его выполнение хорошо платит большие дивиденды дальше по линии.

Единственный минус, который я вижу, заключается в том, что редукторы становятся чрезвычайно большими очень быстро. Кажется, что существует множество ситуаций, когда повторяется один и тот же код с разными именами и повторяется. Мой мозг кричит "функция с параметрами", но это не работает. С другой стороны, именно здесь структура и состояние приложения выражаются во всех деталях, поэтому там обязательно будет много. И когда что-то пойдет не так, как это неизбежно, чистая функция в качестве источника проблемы облегчает отслеживание и исправление.