Бұрыштағы кодты бөлу немесе жалқау модульдер арасында компоненттерді қалай бөлісу керек

Бұл мақала Angular сіздің кодты бөлімдерге қалай бөлетінін жақсы түсінуге мүмкіндік береді.

Егер сіз жоғарыда көрсетілген бұрыштық CLI шығарудан қорқатын болсаңыз немесе кодтың бөлінуі қалай болатынын білгіңіз келсе, онда бұл хабарлама сізге арналған.

Кодты бөлу сізге кейіннен сұраныс бойынша жүктелетін әртүрлі жинақтарға бөлуге мүмкіндік береді. Егер дұрыс қолданылса, жүктеме уақытына үлкен әсер етуі мүмкін.

Мазмұны

  1. Неге мен қамқорлық жасауым керек?
  2. Сорғыштың астына бұрыштық CLI кодты бөлу
  3. Жалқау модульдері бар қарапайым бұрыштық қолдану
  4. Жалқау модульдер арасында компоненттерді қалай бөлуге болады
  5. Қорытынды

Неге мен қамқорлық жасауым керек?

Сіз жаңа бұрыштық жобаны бастадыңыз деп елестетіп көрейік. Сіз бұрыштық қосымшаны қалай құрастыруға болатындығы, қалтаның тиісті құрылымы және ең бастысы, керемет стартап өнімділігін сақтау туралы көптеген ресурстарды оқисыз.

Сіз Angular CLI-ді таңдадыңыз және көптеген жалқау жүктелген функция модульдері бар модульдік қосымшаны жасадыңыз. Әрине, сіз ортақ модуль құрдыңыз, онда сіз жиі қолданылатын директиваларды, құбырларды және компоненттерді орналастырасыз.

Біраз уақыттан кейін сіз өзіңіздің жаңа мүмкіндіктер модуліңіз басқа мүмкіндіктер модульдерінен кейбір функцияларды қажет етсе, сіз осы функцияны сол ортақ модульге ауыстыруға бейім екенсіз деп ойлайсыз.

Бағдарлама дамып, көп ұзамай сіз оның іске қосылу уақыты сіздің (және ең бастысы клиенттің) күтуіне сәйкес келмейтінін байқадыңыз.

Енді сіз күмәнданасыз ...

  • Егер мен барлық құбырларымды, директиваларымды және жалпы компоненттерімді бір үлкен ортақ модульге салып, оны жалқау жүктелген модульдерге импорттасам (онда мен тек импортталған бір немесе екі функцияны қолдансам), бұл шығыс файлдарда пайдаланылмаған кодтардың қайталануын тудыруы мүмкін. .
  • Екінші жағынан, егер мен ортақ мүмкіндіктерді бірнеше ортақ модульдердің арасында бөлсем және әр нақты модульде тек соларды ғана импорттасам, бұл менің қосымшамның көлемін азайтады ма? Немесе бұрыштық барлық осындай оңтайландырулар әдепкіде орындала ма?

Демистификация жасайық!

Сорғыштың астына бұрыштық CLI кодты бөлу

Қазіргі бұрыштық CLI нұсқасы бумаларды жасау үшін веб-буманы пайдаланады. Бірақ соған қарамастан, веб-бетте де кодты бөлуге жауап береді.

Сонымен, веб-бетті қалай жасайтындығын қарастырайық.

Веб-пакет 4 арқылы бөлшектелген модульдерді бөлудің кейбір эвристикасын анықтауға мүмкіндік беретін SplitChunksPlugin енгізілді. Көптеген адамдар бұл конфигурация жұмбақ болып көрінеді деп шағымданады. Сонымен қатар, бұл кодты бөлудің ең қызықты бөлігі.

Бірақ SplitChunksPlugin оңтайландыру қолданылғанға дейін веб-пакет жаңа бөлімді жасайды:

  • әр кіру нүктесі үшін

Бұрыштық CLI келесі кіру нүктелерін теңшейді

негізгі полифилл стильдері

нәтижесінде бірдей атаулар пайда болады.

  • әр динамикалық жүктелген модуль үшін (импорт () синтаксисін пайдаланып, динамикалық импортқа арналған ECMAScript ұсынысына сәйкес келеді)

LoadChildren синтаксисі есіңізде ме? Бұл веб-бетте штуф құруға арналған сигнал.

Енді SplitChunksPlugin-ге көшейік. Оны webpack.config.js оңтайландыру блогында қосуға болады

Angular CLI бастапқы кодын қарастырайық және конфигурация бөлімін табайық:

Бұрыштық CLI 8-де SplitChunksPlugin конфигурациясы

Біз осы жерде cacheGroups опцияларына назар аударамыз, өйткені бұл веб-беттің кейбір жағдайларға байланысты бөлінген бөлшектерді қалай құру туралы «рецепт».

cacheGroups - бұл қарапайым объект, онда кілт - бұл топ атауы. Негізінен, біз кэш тобын жаңа бөлімді құру үшін мүмкін мүмкіндік ретінде қарастырамыз.

Әр топта көптеген конфигурациялар бар және конфигурацияны splitChunks деңгейінен алады.

Жоғарыдағы Angular CLI конфигурациясында көрген параметрлерге тез қарайық:

  • синхрондау және асинхронды блоктар арасындағы модульдерді сүзгілеу үшін пайдалануға болады. Оның мәні бастапқы, асинк немесе барлық болуы мүмкін. бастапқы дегеніміз, файлдарды синхрондау бөлімдеріне импортталған жағдайда ғана оларды файлға қосуды білдіреді. async дегеніміз, егер олар асинк бөліктеріне импортталған болса, оларды тек файлға қосуды білдіреді (async әдепкі бойынша)
  • minChunks веб-бумаға, егер олар кем дегенде 2 бөлік арасында бөлінсе, тек модульдерді қоқысқа енгізуді айтады (әдепкі бойынша 1).
  • атауы веб-бумаға бұл атауды жаңадан жасалған шкаф үшін пайдалану керектігін айтады. Әрқашан бірдей жолды қайтаратын жолды немесе функцияны көрсету барлық жалпы модульдерді бір түйінге біріктіреді.
  • модуль көптеген шоғырланған топтардың астына түскен кезде ең жақсы сәйкестендірілген түйіндерді анықтау үшін қолданылады.
  • Бұл веб-бетте minSize, minChunks, maxAsyncRequests және maxInitialRequests опцияларын елемеуге және әрдайым осы кэш тобына арналған заттарды жасауға кеңес береді. Мұнда бір кішкентай готча бар: егер бұл cacheGroup деңгейінде ескерілмеген параметрлердің кез-келгені берілсе, онда бұл опция әлі де қолданылады.
  • осы кэш тобы таңдайтын модульдерді тексеруді басқару. Біз байқағанымыздай, Angular CLI бұл параметрді барлық node_modules тәуелділіктерін сатушыға ауыстыру үшін қолданады.
  • minSize ең аз мөлшерді анықтау үшін пайдаланылады, байт түрінде, блоктың пайда болуы үшін. Бұл бұрыштық CLI конфигурациясында пайда болмады, бірақ бұл біз білуіміз керек өте маңызды нұсқа. (Бастапқы кодта айтылғандай, ол өндірісте әдепкі бойынша 30кб және дев ортада 10кб)
Кеңес: веб-буманың құжаттары әдепкі мәндерді анықтаса да, мен нақты мәндерді табу үшін веб-буманың бастапқы кодына жүгінемін.

Мұнда еске түсірейік: Angular CLI модульді келесіге ауыстырады:

  • егер модуль node_modules директориясынан келетін болса, сатушы бөлімі.
  • егер бұл модуль асинхронды модульге импортталып, кем дегенде екі модуль арасында ортақ пайдаланылса, әдепкі түйін. Мұнда көптеген әдепкі түйіндерді қолдануға болатындығын ескеріңіз. Мен кейінірек веб-беттің сол топтарға қалай ат қоятынын түсіндіремін.
  • егер бұл модуль асинхронды модульге импортталып, кем дегенде екі модуль арасында бөлініп, әдепкі түйіннің астына түспесе (сәлемдік басымдылық), сондай-ақ ол қандай мөлшерде болмасын (күштің көмегімен)

Теория жеткілікті, жаттығайық.

Жалқау модульдері бар қарапайым бұрыштық қолдану

SplitChunksPlugin процесін түсіндіру үшін біз бұрыштық қосымшаның жеңілдетілген нұсқасынан бастаймыз:

қолданба (a жалқау) және a.component.ts, a.module.ts, ab.component.ts және ab.module.ts │ ├── b (жалқау) │ └── b.component.ts │ └── b.module.ts │ └── c (жалқау) │ └── c.component.ts │ └── c.module. c │ └── cd │ └── cd.component.ts │ └── cd.module.ts │ └── d (жалқау) │ └── d.component.ts │ └── d.module.ts «Ортақ», «ортақ.module.ts» және «app.component.ts», «апп.module.ts»

Мұнда a, b, c және d - жалқау модульдер, демек олар импорт () синтаксисі арқылы импортталады.

a және b компоненттері шаблондарда ab компонентін қолданады. c және d компоненттері CD компонентін қолданады.

Бұрыштық модульдер арасындағы тәуелділіктер

Ab.module мен cd.module арасындағы айырмашылық мынада: ab.module a.module және b.module-ге, ал cd.module - ортақ.module-ге импортталады.

Бұл құрылым біз демистификациялағымыз келген күмәнді нақты сипаттайды. Ab және CD модульдерінің қорытынды шығарылым қай жерде болатынын анықтайық.

Алгоритм

1) SplitChunksPlugin алгоритмі бұрын жасалған барлық түйіндерге индекстеуден басталады.

индекс бойынша бөліктер

2) Содан кейін ол chunkSetsInGraph Map-ты толтыру үшін компиляцияның барлық модульдеріне ілінеді. Бұл сөздікте қай кодекстің бірдей кодты бөлісетіндігі көрсетілген.

chunkSetsInGraph

Мысалы, 1,2 негізгі, полифиллерлік жол дегеніміз, екі бөлімде кем дегенде бір модуль бар: негізгі және полиэтилинг.

а және b модульдері модульден бірдей кодты бөледі, сондықтан біз жоғарыдағы комбинацияны байқаймыз (4,5).

3) Барлық модульдерді аралап өтіп, белгілі бір cacheGroup үшін жаңа бөлік құруға болатындығын анықтаңыз.

3a) Біріншіден, веб-бум модулді cacheGroup-қа thecacheGroup.test қасиетін тексеру арқылы қосуға болатындығын анықтайды.

ab.module тесттері

әдепкі тест анықталмаған => жарайды
жалпы тест undefined => ok
жеткізушінің тексеру функциясы => жалған

әдепкі және жалпы кэш тобы ең жақсы қасиетті анықтамады, сондықтан оны өтуі керек. сатушының кэштегі тобы содан кейін модульдер модулін ғана қамтитын сүзгі бар функцияны анықтайды.

cd.module тесттері бірдей.

3b) Енді барлық түйіспелерді аралап өту керек.

Әр модуль оның қандай бөліктерде пайда болатындығын түсінеді (module.chunksIterable қасиеті арқасында).

ab.module екі жалқауға әкелінеді. Сонымен оның комбинациясы (4), (5) және (4,5) болады.

Екінші жағынан, cd.module тек бөлісілген модульде импортталады, демек ол тек торапқа ғана әкелінеді. Оның комбинациясы тек (1).

Содан кейін minChunk өлшемі бойынша плагиндердің комбинациясы сүзіледі:

егер (chunkCombination.size 

Ab.module (4,5) тіркесімі болғандықтан, ол осы тексеруден өтуі керек. Бұл туралы cd.module туралы айта алмаймыз. Қазіргі уақытта бұл модуль негізгі магистральда тұруға мүмкіндік береді.

3c) cacheGroup.chunkds тағы бір тексеру бар (бастапқы, асинк немесе барлығы)

ab.module асинк (жалқау жүктелген) бөліктеріне импортталады. Бұл әдепкі және жалпы кэш топтарын талап етеді. Осылайша, ab.module екі жаңа мүмкіндігіне қосылады (әдепкі және жалпы).

Мен бұған дейін уәде берген едім, міне барамыз.

Веб-бетте SplitChunksPlugin жасаған шкафтың аты қалай жасалады?

Оның жеңілдетілген нұсқасы ретінде ұсынылуы мүмкін

қайда:

  • groupName - бұл топтың атауы (біздің жағдайымызда әдепкі емес)
  • ~ әдепкіАвтоматтыАтаҚызметі
  • chunkNames бұл топқа кіретін барлық аттардың тізімін білдіреді. Бұл атау fullPath жолы сияқты, бірақ қиғаш сызықтың орнына -.

Мысалы, dd-модулі d папкасында d.module файлы бар екенін білдіреді.

Осылайша, импортты ('./ a / a.module') және импортты ('./ b / b.module') қолдана отырып, аламыз

Әдепкі шегі атауының құрылымы

Тағы бір айта кететін жәйт, шұңқыр атауының ұзындығы 109 таңбадан асқанда, веб-пакет оны қиып, соңында бірнеше хэш қосады.

Бірнеше жалқау модульдер арасында кодты бөлетін үлкен сын есімнің құрылымы

Біз барлық мүмкін болатын жаңа бөлімдер туралы білетін және қандай модульдерден тұруы керектігін және сол модульдер тұрған жерде орналасқан түйіндерді білетін chunksInfoMap толтыруға дайынбыз.

chunksInfoMap

Ықтимал кескіндерді сүзетін уақыт келді

Ең жақсы сәйкес келетін жазбаны табу үшін SplitChunksPlugin chunksInfoMap элементтеріне арналған ілмектер. Ол нені білдіреді?

Әдепкі кэш тобында 10 артықшылық бар, ол артық салмақтан тұрады (тек 5). Бұл дегеніміз, әдепкі ең жақсы сәйкес келетін жазба және оны алдымен өңдеу керек.

Қалған барлық талаптар орындалғаннан кейін, веб-беттің барлық модульдерін chunksInfoMap сөздігіндегі басқа мүмкін бөліктерден алып тастайды. Егер модуль қалмаса, модуль жойылады

Осылайша, әдепкі ~ aa-module ~ bb-модуль қарапайым шкафтан басым болады. Соңғысы модульдердің бірдей тізімін қамтығандықтан жойылады.

Соңғысы, бірақ ең маңызды қадам - ​​кейбір оңтайландыруларды (қайталануларды жою сияқты) жасау және maxSize сияқты барлық талаптардың орындалғанына көз жеткізу.

SplitChunksPlugin бастапқы кодын мына жерден табуға болады

Біз веб-беттерді үш түрлі жолмен құратындығын анықтадық:

  • әр жазба үшін
  • динамикалық жүктелген модульдер үшін
  • SplitChunksPlugin көмегімен ортақ код үшін
Бөліктердің типі бойынша CLI-дің бұрыштық шығысы

Енді ортақ кодты сақтаудың ең жақсы әдісі туралы күмәнімізге оралайық.

Жалқау модульдер арасында компоненттерді қалай бөлуге болады

Біздің қарапайым Бұрыштық қосымшамыздан көріп отырғанымыздай, веб-бетте ab.module үшін бөлінген тор құрылды, бірақ негізгі бөлімге cd.module енгізілді.

Осы посттағы маңызды оқиғаларды қысқаша қорытындылайық:

  • Егер біз барлық ортақ құбырларды, директивалар мен жалпы компоненттерді бір үлкен ортақ модульге салып, оны барлық жерге (синхрондау және асинхронды бөліктер ішінде) импорттайтын болсақ, онда бұл код біздің негізгі негізгі бөлігімізде болады. Егер сіз бастапқы жүктеме өнімділігін алғыңыз келсе, онда бұл бару жолы.
  • Екінші жағынан, егер біз жалқау жүктелген модульдердің арасында жиі қолданылатын кодты бөлетін болсақ, онда жаңа ортақ блок құрылып, сол жалқау модульдердің кез-келгені жүктелген жағдайда ғана жүктеледі. Бұл қосымшаның бастапқы жүктемесін жақсартуы керек. Бірақ мұны ақылмен жаса, өйткені кейде жеке нөмірге қосымша сұраныс болған кезде кішкене кодты бір ұяшыққа салған дұрыс.

Қорытынды

Енді сіз Angular CLI-дің нәтижелерін нақты түсініп, кіру, динамикалық және SplitChunksPlugin түйіндерін қолдана отырып бөлінгенді ажыратуыңыз керек деп үміттенемін.

Бақытты кодтау!