Drejtimi i AngularJS 1.6 në Angular 5 (krah për krah) Pjesa 3: Ndërtimi, vendosja dhe më gjerë

Lëshojeni!

Kjo është një pjesë 3 e Running AngularJS 1.6 në Angular 5 (krah për krah), ju mund të lexoni "pjesa 1" dhe "pjesa 2".

Kemi përfunduar veçoritë e reja dhe tani është koha për t'i lëshuar në prodhim.

Sot, ne dëshirojmë të ndajmë përvojën tonë me procesin e lëshimit duke përfshirë

• Ndërtimi i një pakete lëshimi
• Vendoseni në kovën S3
• Mesimet e mesuara

Ndërtimi i një pakete lëshimi

AngularJS

Në AugularJS, ne përdorëm Grunt (gjeneruar nga Yeomen) për të krijuar një paketë lëshimi. Ndërtimi i Grunt kryen:

• Ndërtoni një skedar css nga scss
• Konvertoni shabllonet html në një skedar të vetëm js
• Pako skedarët js duke përfshirë bibliotekat në një skedar të vetëm js
• Ugify js dhe css
• Rishikoni emrat e skedarëve
• Përditëso/minifiko indeksin.html

Paketa e lëshimit përmban një grup skedarësh js/css/image/font me index.html.

Këndore

Në Angular, ne përdorim Angular CLI, i cili përdor Webpack brenda. Ekzistojnë 3 hapa kryesorë për ndërtimin e një pakete lëshimi:

1. ndertohet me cli te ri kendore
2. zvogëloj / shëmtuar me një minifier / shëmtuar gjenerik
3. Revizionizo (Ngarkimi i detyruar i botimit të ri)

Arsyeja që duhet ta minimizojmë/shpërtojmë vetë është se aplikacioni ynë AngularJS nuk funksionon kur përdorim procesin e shëmtuar Angular CLI! Me fjalë të tjera, ndërtimi Angular CLI nuk është i pajtueshëm me @angular/upgrade që përdorim për të ekzekutuar AngularJS krah për krah. Është një surprizë e madhe duke qenë se ekipi Angular po ofron mjete dhe dokumentacion gjithëpërfshirës për modulin e përmirësimit. Ka shumë çështje që depoja Angular CLI ankohet për "të".

Ndërto me Angular CLI 1.7.4

Së pari duhet të sigurohemi që aplikacioni AngularJS të jetë i shëmtuar për një minifikues/përtëritës gjenerik duke konvertuar çdo injeksion të nënkuptuar të varësisë në injeksion të qartë të varësisë:

someModule.controller('MyController', function($scope, greeter) {
    // ... 
});

to

someModule.controller('MyController', ['$scope','greeter', function($scope, greeter) {
    // ...
}]);

Kur injeksioni AngularJS të jetë fiksuar, ne mund të ekzekutojmë ndërtimin (Ju lutemi shihni dokumentin zyrtar për opsionet).

ng build --aot true --build-optimizer true --sourcemaps false --extract-css true --named-chunks false

Më poshtë është përmbajtja e drejtorisë dist. Ka katër skedarë të paketës JS duke përfshirë inline.bundle.js, main.bundle.js, polyfills.bundle.js dhe scripts.bundle.js dhe një skedar CSS, styles.bundle.css. Në këtë fazë, skedarët JS janë kaq të mëdhenj, gjithsej 20 MB.

Vlen gjithashtu të përmendet se ndërtimi ng nuk i bashkon skedarët e pjesshëm html si skripta ndryshe nga detyra AngularJs Grunt ngTemplate. Kjo do të na detyrojë të kopjojmë direktorinë ng1 për të shërbyer skedarë të pjesshëm html në kohën e ngarkimit të faqes.

Zvogëlohet/Shtrohet

Ne kemi përdorur versionin 3.4.2 "uglify-js" dhe versionin 0.0.29 "uglifycss":

echo "run js uglifier"
  node --stack_size=100000 uglifyjs ./dist/inline.bundle.js > ./dist/inline.01.bundle.js
  node --stack_size=100000 uglifyjs ./dist/polyfills.bundle.js > ./dist/polyfills.01.bundle.js
  node --stack_size=100000 uglifyjs ./dist/scripts.bundle.js > ./dist/scripts.01.bundle.js
  node --stack_size=100000 uglifyjs ./dist/main.bundle.js > ./dist/main.01.bundle.js
echo "run css uglifier"
  node uglifycss ./dist/styles.bundle.css > ./dist/styles.01.bundle.css

Procesi zvogëloi madhësitë e skedarëve në pothuajse gjysmën, që është ende mbi 10 MB. Ky është 4 herë më i madh se aplikacioni i mëparshëm AngularJS (2,5 MB duke përfshirë të gjithë skedarët e pjesshëm html).

Revizionizo (Ngarkimi i detyruar i botimit të ri)

Së fundi, ne duhet të rishikojmë skedarët në mënyrë që të detyrojmë ringarkimin e paketave të aplikacionit. Ekzistojnë një sërë mjetesh të disponueshme për një detyrë me rrotullim, duke përfshirë "grunt" dhe "webpack". (ne kemi përdorur një detyrë rev me porosi e cila ekziston tashmë në zinxhirin tonë të veglave).

Vendoseni në S3

DataFarming është pritur në AWS S3 si një përmbajtje statike dhe shërbehet duke përdorur AWS CloudFront. Ne përdorim AWS CLI për të sinkronizuar drejtorinë dist me kovën S3 dhe më pas zhvlerësojmë cache-in CloudFront. Nuk ka asnjë ndryshim në këtë pjesë dhe tani kemi një publikim të ri!

Mesimet e mesuara

Së fundi, ne dëshirojmë të ndajmë mësimet tona të nxjerra mbi këtë strategji migrimi.

Pjesë të mira

• Pa defekte: Në përgjithësi, migrimi është i qetë dhe nuk ka probleme teknike në ndërtimin e një veçorie të re duke përdorur Angular duke përdorur veçoritë ekzistuese të implementuara në AngularJS
• Bota e re e guximshme: Tani mund të përfitojmë plotësisht nga kombinimi Angular Component Architecture me NGRX si dhe të përdorim komponentët UI të disponueshëm në Angular Material
• Raftoni me sistemin eko Angular: Angular është tani 7 dhe ofron më shumë veçori që na ndihmojnë të përmirësojmë zhvillimin/veçoritë e aplikacionit tonë (Schematics, Univeersal, Angular CDK etj.)

Pjesë të këqija

• Problemet e ndërtimit: ng build nuk e kupton që ne po përfshijmë AngularJS duke përdorur modulin e përmirësimit dhe nuk ka asnjë diskutim apo udhëzues të qartë se si mund ta zgjidhni atë. Ekipi Angular CLI gjithashtu thotë qartë se ata nuk duan që ne të prekim drejtpërdrejt asnjë nga detyrat e paketës së internetit. Pra, çështja me të cilën përballemi duhej të zgjidhej vetë
• Madhësia e aplikacionit: Aplikacioni është bërë dukshëm më i madh në krahasim me versionin e mëparshëm (4 herë më i madh se aplikacioni AngularJS). Ne kemi ndërtuar një numër aplikacionesh duke përdorur Angular 2, 4, 5, 6 dhe 7 dhe madhësia e një pakete lëshimi mund të jetë 500 KB ~ 5 MB në varësi të bibliotekave të përdorura për një projekt. Ne kemi përjetuar gjithashtu versione të mëparshme të ng build me optimizime të etur, shpesh e thyen aplikacionin pa asnjë arsye dhe ne u detyruam të lëshonim (në heshtje) një version pa optimizuar paketën e lëshimit.
• Përfitim për përdoruesit fundorë: Si zhvillues, ky projekt është i suksesshëm në një mënyrë që ne mund të shfrytëzojmë teknologjinë më të re për aplikacionin, nuk është aspak i dobishëm për përdoruesit përfundimtarë për shkak të rritjes së madhësisë . Ky është veçanërisht një problem për njerëzit që hyjnë në aplikacionin tonë në një fushë me një pajisje celulare dhe ata lehtë mund të ndalojnë përdorimin e tij për shkak të kohës së ngarkimit.

A e përdorim këtë arkitekturë për një aplikacion tjetër AngularJS?

Motivimi më i madh i kësaj strategjie migrimi është shtimi i veçorive të reja duke përdorur teknologjitë më të fundit duke ripërdorur implementimin e personalizuar (shërbimet, direktivat dhe të gjitha pjesët e ripërdorshme) të aplikacionit AngularJS.

DataFarming definitivisht e ka arritur qëllimin dhe ka përmirësuar ndjeshëm zhvillimin e një veçorie të re nga perspektiva e zhvillimit. Është gjithashtu ekonomik pasi ne jemi në gjendje të përdorim të gjithë zbatimin ekzistues.

Kështu që ne kemi vendosur të provojmë një projekt tjetër më të madh.

Rasti: Projekt i bazuar në UI Bootstrap Angular

Shumë nga aplikacionet tona AngularJS përdorin AngularJS UI Bootstrap (i cili përdor Bootstrap 3). Problemi me të cilin u përballëm shpejt ishte Bootstrap me fuqi Angular (UI Bootstrap për Angular 2 ~ 7) duke përdorur Bootstrap 4 dhe nuk mund t'i përdorni thjesht këto 2 versione të Bootstrap krah për krah. Fundi i tregimit.

Zgjidhja jonë për aplikacionet e bazuara në UI Bootstrap është të ekzekutoni 2 aplikacione të vetme (AngularJS dhe Angular) krah për krah duke pasur 2 hyrje në aplikacion (d.m.th. index-1.html dhe index-2.html). Çdo shërbim/direktivë e zbatuar në AngularJS e kërkuar në Angular thjesht portohet (kopjohet) në Angular duke rishkruar (kryesisht kopjohet dhe ngjitet me një modifikim të vogël) në TypeScript. Drejtimi thjesht ngarkon index-1.html ose index-2.html në varësi të rrugës.

konkluzioni

Fillimisht jemi shumë të emocionuar me modulin e përmirësimit të ofruar nga ekipi Angular. Ata siguruan një dokument teknik gjithëpërfshirës të thelluar për këtë temë, megjithatë ai nuk ishte praktik dhe nuk na ndihmoi të bënim se çfarë strategjie duhet të marrim për sa i përket përvojës së përdoruesit.

Në përvojën tonë, procesi i zhvillimit ka qenë i mrekullueshëm dhe ne kemi ndërtuar funksionin tonë të ri shpejt dhe bukur duke përdorur sistemin Angular echo. Sidoqoftë, nuk është vërtet miqësor si përdorues fundor pasi aplikacioni është dukshëm më i madh për t'u ngarkuar.

Sigurisht që mund të shpenzojmë më shumë kohë për të optimizuar më tej, por nuk është aq e drejtpërdrejtë pasi nuk jemi në gjendje të 'përshtatim' funksionimin e ndërtimit Angular CLI dhe nuk ka asnjë garanci nëse një optimizim i personalizuar do të funksiononte në versionin e ardhshëm si Angular 6 dhe 7. Për shembull, Angular 6 përdor angular.json në vend të .angular-cli.json dhe është një strukturë rrënjësisht e ndryshme dhe ju duhet të merreni me të gjitha ndryshimet e brendshme të procesit vetë.

Ky është padyshim një pengesë e madhe e përdorimit të zhvillimit në qendër të Angular CLI në krahasim me përdorimin e një pakete uebi tradicionale pasi nuk mund ta hakoni lehtë procesin tuaj të ndërtimit për një kërkesë të veçantë (p.sh. futja e aplikacionit AngularJS ose përballja me biblioteka të tjera të integruara).

Si përfundim, nëse nuk keni shumë biblioteka të palëve të treta në aplikacionin AngularJS dhe madhësia e aplikacionit tuaj nuk është e rëndësishme, kjo strategji do të funksionojë për ju. Nëse përdorni UI Bootstrap, 2 aplikacione me një faqe krah për krah janë mënyra për të shkuar.