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

Дял

Здравейте, хора! Когато работехме по версия 3.0.0, основната ни цел беше да добавим мързеливо зареждане към рамката и да я улесним максимално. Въпреки че все още обозначаваме мързеливото зареждане като бета/настройка по подразбиране, много разработчици, които добавят мързеливо зареждане към своите приложения, задават въпроси относно най-добрите практики и примери. Мислех, че това гарантира публикация по темата, за да се потопите как да настроите приложение за мързеливо зареждане.

зареждане

Забележка: подходът за мързеливо зареждане тук е за версия 3.0.0 и по-нова. Тъй като ленивото зареждане все още е бета/експериментално, подробностите за това може да се променят в бъдеще.

Основният модул

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

Нека вземем това по едно парче и използвайте празно приложение за стартиране, за да се ориентираме.

Сега, ако отворим нашия файл src/app/app.module.ts, можем да проверим NgModule по подразбиране:

Тук можем да видим, че импортираме компонента MyApp и компонента HomePage. Сега искаме да премахнем компонента HomePage от този модул и да го заредим само когато имаме нужда от него. Така можем да премахнем препратката към HomePage в декларации и entryComponents, както и изявлението за импортиране.

И така, как можем да заредим лениво HomePage? Можем да му предоставим свой собствен NgModule, който ще капсулира всичко, от което компонентът се нуждае, за да функционира.

Нека да създадем нов файл src/pages/home/home.module.ts и да го скелираме.

Тук не се случва много, но IonicPageModule вероятно е нещо ново. Подобно на IonicModule в главния app.module.ts, това казва на Ionic какъв компонент трябва да зареди или да осигури за тази част. Можем да експортираме празен клас и да завършим нашия модул. Последната част, която трябва да направим сега, е да украсим нашия компонент HomePage.

В src/pages/home/home.ts нека добавим декоратора @IonicPage.

Този декоратор на IonicPage е начинът, по който Ionic генерира подходящите картографирания и URL плъзгачи за вашето приложение по време на изграждане. IonicPage има няколко опции, които можете да преминете към него, но засега няма да се тревожим за тях. Всичко, което трябва да знаем, е, че когато искаме да навигираме или да препращаме към този компонент в нашия код, можем да предадем низа HomePage вместо препратка към класа директно.

Говорейки за това, предстои ни последното почистване. В src/app/app.component.ts имаме оператор за импортиране и препратка към HomePage. Нека да премахнем оператора за импортиране и след това за rootPage можем да го зададем на „HomePage“ .

Честито! Вече сте преминали през процеса на мързеливо зареждане на началната страница!

Добре, така че на основно ниво тук не се случва много, той е концентриран предимно около организирането на кода ви и създаването на NgModule s за страниците, които искате да се зареждат мързеливо, и добавянето на декоратора @IonicPage към компонента.

Събрах няколко примера за това как това може да работи за нещо малко по-сложно, като приложение, базирано на Tabs.

Готино, така че защо да си правиш труда?

Сега, когато сме мързеливи при зареждането на HomePage, какво да очакваме да видим? Ако започнем да проверяваме приложението си, можем да видим какво изпращаме по мрежата.

Ако разгледаме какво изпращаме по мрежата, имаме нашия пакет main.js (който включва нашия основен компонент на приложението, ъглови и първоначалните ни зависимости) и след това 0.main.js, който е само нашата HomePage. Нашата основна част сега е много по-малка и може да бъде заредена много по-бързо. Същото важи и за нашия начален блок, изпращаният код е само това, което този парче изисква, така че се зарежда много по-бързо.

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

Сега нашето малко приложение може да изглежда малко измислено, но тъй като приложенията започват да растат, способността за мързеливо зареждане на допълнителни компоненти става много по-важна. Помислете за приложения с над 50 различни страници и много повече компоненти на потребителския интерфейс. Зареждането на всичко това отпред е много скъпо. Вместо това, ако можете да заредите само 2-4 различни компонента отпред, а мързеливите - останалите, потребителите ще имат много по-добро преживяване.

Какво следва

Наистина сме надраскали само мързеливата товарна повърхност и концепциите зад нея. В последващ пост ще разгледаме как можем да структурираме приложението си, за да можем по-добре да поддържаме мързеливо зареждане на: Компонент, Директиви и Тръби.