За да постигнем това, трябва да приложим две концепции. Мързеливо зареждане на модули чрез angular и също така лениво създаване на състоянието в магазина, след като модулът е лениво зареден.

Очаквам да имам основни и работни познания за ngrx store и angular

Голяма картина (Архитектура и защо имаме нужда)

Lazy Loading Angular 2

Angular 2 Router предоставя функцията за мързеливо зареждане на функционалните модули.

С мързеливото зареждане получаваме по-нисък начален полезен товар и по този начин подобряваме времето за стартиране. В голямо приложение е много важно да разделим домейните на функционални модули и след това да зареждаме тези модули на мързелив начин, ако използваме тези модули.

Да кажем например, че имаме голямо приложение и два от домейните са

продукт

фактуриране

Тогава продуктовият мениджър може да има достъп само до продуктовата част на приложението, за да създава и редактира продуктите, а мениджърът за фактуриране има достъп само до частта за фактуриране на приложението, за да генерира фактурите за клиентите.

Следователно има смисъл да не зареждате модула за фактуриране за продуктовия мениджър, след като продуктовият мениджър влезе, тъй като той или тя може никога да не се нуждае от него.

Магазин NgRx

NgRx store е внедряването на редуциращия модел заедно със силата на наблюдаемите.

С прости думи можем да мислим за магазина като за проста ъглова услуга, съдържаща състоянието, обвито в наблюдаема.

За промяна на състоянието просто изпратете действие до магазина. Редукторите в магазина създават новото състояние въз основа на действието и неговия полезен товар.

Компонентите, абонирани за магазина, ще получат новото състояние и по този начин компонентът ще изобрази това ново състояние.

Магазинът разделя управлението на състоянието от вашите компоненти и услуги и също така насърчава неизменността на управлението на състоянието.

В горната диаграма View е компонентът или услугата, която е абонирана за магазина и показва текущото състояние, присъстващо в магазина.

Ако изгледът трябва да бъде актуализиран (щракване върху бутон или заявка на сървър), тогава изгледът изпраща действие до магазина чрез дипатчера. Редукторите в магазина създават новото състояние и избутват това ново състояние към основния субект на поведение, обгръщайки състоянието. Тъй като изгледът е абониран за магазина и следователно ще получи новото състояние и ще рендира отново това ново състояние.

Сега нека приложим горните концепции към приложението.

Да вземем приложение като пощенска кутия, където след като влезем, виждаме две връзки

Табло за управление

Пощенска кутия

Така че ние проектираме това, ще създадем два модула с функции, т.е. един за таблото и един за пощенската кутия.

по подразбиране потребителят ще пренасочи към таблото за управление, където потребителят може да види собствената си информация. Сега тук, за да намалим първоначалния полезен товар, може изобщо да не зареждаме модула на пощенската кутия и просто да заредим всички js и html за таблото за управление първоначално. Също така състояние за пощенската кутия няма да бъде създадено в магазина, тъй като все още не е необходимо.

Само имайте предвид, че се опитваме да постигнем две неща

  1. Мързеливо зареждане на модула на пощенската кутия
  2. Мързеливо създайте състоянието, необходимо за mailox

Ако потребителят реши да провери пощенската си кутия, тогава само мързелив заредете модула за пощенска кутия и създайте състоянието също в магазина.

Така че в горната снимка можете да видите, че в магазина е създадено само състояние на потребителска информация, но не и състояние на пощенска кутия.

И кодът, и състоянието, свързани с пощенската кутия, не се зареждат или създават в паметта на браузъра.

След като щракнете върху връзката mailmox

Когато щракнете върху връзката към пощенската кутия, кодът и състоянието се изтеглят и създават за пощенската кутия. Правим ajax заявка, за да получим папките за потребителя. Можем да видим входяща кутия и папка за боклук.

Да видим кода за настройка.

  1. Основен модул на приложението

По-горе е основният модул на приложението.

  • RouterModule.forRoot(routes) - за конфигуриране на маршрутите за root приложение
  • StoreModule.forRoot(reducers)- за прикачване на основното състояние в хранилището

нека поставим фокуса върху маршрутите. Модулът на таблото се зарежда бързо и по този начин ние импортираме модула на таблото. Пренасочваме към /dashboard. В модула Dashboard ние казваме на angular рутера да изобрази компонента на таблото за управление за пътя /dashbord.

Компонентът на таблото за управление извлича потребителската информация от сървъра. Обикновено в ngOnit на компонента на информационното табло се прави заявка и при нейния успех просто се изпраща действие до магазина за актуализиране на userInfo. Също така в ngOnit изберете състоянието на потребителската информация от магазина чрез селектори и просто изобразете това състояние в html компонента.

За маршрута на maibox ние указваме само литерала на низа, указващ името на файла, тъй като модулът все още не е зареден. След като маршрутът е активиран, angular чрез webpack ще получи кода на модула.

Функцията StoreModule forRoot се извиква с редуктора, съдържащ само потребителската информация, т.е. rootReducer. Тази функция forRoot ще регистрира своите доставчици и също ще експортира всички свои типове.

Само за да обобщим в основния модул на приложението имаме два forRoot

един за рутера. RouterModule.forRoot(маршрути)

един за магазина. StoreModule.forRoot(редуцири)

2. Редуктор на корените

root редукторът съдържа само потребителската информация, която се изисква от таблото за управление.

3. Модул за пощенска кутия

Този модул се зарежда лениво от рутера Angular. Но как да посочите на магазина да създаде състояние за пощенската кутия. съвет (StoreModule.forFeature)

нека се съсредоточим върху StoreModule.forFeature. Тук казваме на магазина да създаде състояние на пощенската кутия и да обедини това състояние с текущото основно състояние (userInfo). Подобно е на функцията RouterModule.forChild, където store няма да регистрира отново услугите към доставчика, както вече е направено в модула на приложението чрез forRoot.

4. Редуктор на пощенска кутия

Този редуктор просто следва същите концепции. Състоянието на пощенската кутия съхранява всички налични папки в пощенската кутия. Ngrx store ни дава хубавата функция за създаване на селектор за състоянието на функционалния модул, т.е. createFeatureSelector.

5. Компонент за пощенска кутия

Този компонент получава папките от сървъра и при успех изпраща действие за актуализиране на хранилището със състоянието на папките. Той също така избира състоянието на пощенската кутия от магазина, така че да може да го визуализира.

Изходният код може да бъде намерен тук

Резюме

  • Важно е да разделите домейните на различни функционални модули
  • Нетърпеливо зареждайте само онези модули, които са необходими при стартиране
  • Нетърпеливо създайте състоянието в магазина само за нетърпеливо заредените модули
  • Създайте състоянието в магазина, когато и когато модулите се зареждат чрез помощната програма StoreModule.forFeature().