Кутовий 6 - навіщо використовувати @ ngrx / store, а не введення служби

Нещодавно я вивчаю Angular 6 з @ ngrx / store, в той час як одним з підручників є використання @ ngrx / store для управління державою, однак я не розумію переваг використання @ ngrx / store за лаштунками.

Наприклад, для простої дії входу та реєстрації, раніше за допомогою служби (назвемо її AuthService) ми могли б використовувати її для виклику серверного API, зберігання "userInfo" або "token" в AuthService, перенаправлення користувача на "HOME" сторінки, і ми можемо вводити AuthService в будь-який компонент, де нам потрібно отримати userInfo, використовуючи DI, який просто один файл AuthService обробляє все .

Тепер, якщо ми використовуємо @ ngrx / store, нам потрібно визначити Action / State / Reducer / Effects / Selector, які, ймовірно, потрібно писати в 4 або 5 файлах для обробки вище дії або події, то іноді все одно нам потрібно викликати серверний api використання сервісу, який здається набагато складнішим і зайвішим ...

У іншому сценарії я навіть бачу, що якась сторінка використовує @ ngrx / store для зберігання об’єкта або списку об’єктів, таких як дані сітки. , це для якогось використання магазину в пам'яті?

Тож повернемося до запитання, чому ми використовуємо @ ngrx / store над магазином реєстрації послуг тут, у проекті Angular? Я знаю, що це для " ДЕРЖАВНОГО УПРАВЛІННЯ ", але що саме таке "ДЕРЖАВНЕ УПРАВЛІННЯ"? Це щось на зразок журналу транзакцій і коли він нам потрібен? Чому нам це вдається на передній панелі? Будь ласка, не соромтеся поділитися своїми пропозиціями чи досвідом у зоні @ ngrx / store!

Я думаю, вам слід прочитати ці два дописи про магазин Ngrx:

• Кутові сервісні рівні: Redux, RxJs та Ngrx Store - коли використовувати магазин і чому?
• Магазин Ngrx - Керівництво з архітектури

Якщо перший пояснює основні проблеми, які вирішує Ngrx Store, він також цитує це твердження з React How-To ", яке, схоже, однаково стосується оригінальних Flux, Redux, Ngrx Store або будь-якого рішення магазину загалом":

Ви дізнаєтесь, коли вам знадобиться Flux. Якщо ви не впевнені, чи потрібно це вам, воно вам не потрібно.

Для мене магазин Ngrx вирішує кілька питань. Наприклад, коли вам доводиться мати справу з спостережуваними і коли відповідальність за деякі спостережувані дані розподіляється між різними компонентами. У цьому випадку дії сховища та редуктор гарантують, що модифікація даних завжди буде виконуватися "правильно".

Він також забезпечує надійне рішення для кешування запитів http. Ви зможете зберігати запити та відповіді на них, щоб переконатися, що запит, який ви робите, ще не має збереженої відповіді.

Другий допис - про те, що змусило подібні рішення з’явитися у світі React через проблему з непрочитаними повідомленнями Facebook.

Щодо вашого рішення щодо зберігання даних, що не забуваються, у сервісах. Це чудово працює, коли ви маєте справу з постійними даними. Але коли декільком компонентам доведеться оновити ці дані, ви, мабуть, зіткнетеся з проблемами виявлення змін та неправильними проблемами оновлення, які ви могли б вирішити за допомогою:

• візерунок спостерігача з приватною темою public Observable та наступною функцією
• Магазин Ngrx

Існує також 3-й варіант, наприклад, наявність даних у службі та використання служби безпосередньо в html *ngFor="let item of userService.users". Отже, коли ви оновлюєте userService.usersслужбу після того, як дія додавання або оновлення автоматично відображається у форматі html, немає необхідності в будь-яких спостережуваних, подіях чи магазині.

Якщо дані у вашому додатку використовуються в декількох компонентах, потрібна якась служба для обміну даними. Для цього існує багато способів.

Помірно складний додаток врешті-решт буде виглядати як зовнішня структура інтерфейсу, при цьому обробка даних здійснюється в сервісах, виставляючи дані через спостережувані компоненти.

Одного разу вам потрібно буде написати якийсь API для своїх служб передачі даних, як отримувати та виводити дані, запити тощо. Багато правил, таких як незмінність даних, і чітко визначені окремі шляхи для модифікації даних. Не на відміну від серверної серверної частини, але набагато швидше та швидше реагує, ніж виклики API.

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