Ar mums vis dar reikia „JavaScript“ sistemų?

Kaip interneto kūrėjas stengiuosi reguliariai vertinti savo įrankių rinkinį ir nustatyti, ar galiu apsieiti be to ar kito įrankio. Neseniai aš tyrinėjau, kaip lengva sukurti sudėtingą „front end“ programą be „front end“ sistemos.

Kas yra „JavaScript“ sistema?

Paprasčiau tariant, „JavaScript“ sistema yra įrankis, kurį galite panaudoti kurdami pažangias žiniatinklio programas, ypač SPA.

Tą dieną žiniatinklio kūrėjai, naudodamiesi „vanilla JS“ ir „jQuery“, įdiegtų „front end“ logiką. Tačiau, kai priekinės programos tapo vis sudėtingesnės, įrankiai išaugo, kad atitiktų šį sudėtingumą.

Šiandien populiarios sistemos turi keletą pagrindinių bruožų. Daugelyje „front end“ sistemų / bibliotekų, nuo „Vue“ iki „React“, pateikiama šiokia tokia kombinacija:

  • Būsenos ir vaizdo sinchronizavimas
  • Maršrutai
  • Šablonų sistema
  • Daugkartiniai komponentai

Ar vis dar reikalingos sistemos?

Tai priklauso nuo to, kaip paryškinsite būtiną žodį . Daugelis teigia, kad „front end“ sistemos nėra ir niekada nebuvo reikalingos. Vis dėlto jie yra labai naudingi įrankiai.

Taigi kyla klausimas: ar pagrindai yra šiandieninis „jQuery“? Ar jų išspręstas problemas išspręs tokie pakeitimai kaip DOM API?

Sunku pasakyti, tačiau pažangiosios JS, žiniatinklio komponentų specifikacijos ir lengvai konfigūruojami kūrimo įrankiai, sukūrė SPA be sistemos taip lengva, kaip kada nors anksčiau.

Norėdami tai išnagrinėti toliau, aš sukūriau vieno puslapio programą, naudodamas tik „vanilla JavaScript“, vietinius interneto komponentus ir „Parcel“. Kelyje buvo keletas keblumų ir sunkumų, kurie išryškino JS sistemų stipriąsias puses.

Tuo pačiu metu, kai perėjau pradines kliūtis, nustebau, kaip paprasta buvo sukurti vieno puslapio programą naudojant tik vanilės JS.

Apžvalga

Paraiška yra paprasta. Tai receptų programa, turinti pagrindines CRUD galimybes. Vartotojas gali sukurti, redaguoti, ištrinti, parankinius ir filtruoti receptų sąrašą.

Komponentai

Interneto komponento kūrimas taip pat nesudėtingas. Sukuriate pratęsiamą klasę HTMLElement( HTMLParagraphElementir pan.), Tada naudokite tą klasę norėdami apibrėžti pasirinktinį elementą.

Taip pat galite naudoti gyvavimo ciklo kabliukus, tokius kaip „ connectCallback“, „disconnectedCallback“, „attributeChangedCallback“.

Maršrutai

Receptų programos maršrutas taip pat yra gana paprastas. Atsižvelgdamas į navigacijos įvykį, programos turinį nustatiau pagal atitinkamą žiniatinklio komponentą.

Iš pradžių naudojau „nilla“ paketą „Vanilla JS Router“. Naudojant naršyklės istorijos API nėra taip sudėtinga įdiegti savo kodą mažiau nei 100 kodų eilutėse! Pastaba: aš neįgyvendinu tikrai sudėtingos logikos, tokios kaip maršruto apsaugos.

Tai greita santrauka. Noriu, kad šis straipsnis būtų pakankamai ilgas. Aš galiu parašyti tolesnį pranešimą su išsamesniu paraiškos paaiškinimu. Aš įdiegiau keletą įdomių funkcijų, tokių kaip begalinis slinkimas, pasirinktinis „drag and drop“ įkėlėjas ir dar daugiau!

Retrospektyva

Sukūręs programą, užtrukau šiek tiek laiko galvoti apie viso proceso pliusus ir minusus nuo pradžios iki pabaigos. Pradėsiu nuo blogų žinių.

Minusai

Specifikacija vis dar keičiasi

Žiniatinklio komponento specifikacija yra ir sena, ir nauja. Tai gyvuoja daug ilgiau, nei manyčiau iš pradžių. Pirmą kartą 2011 m. „Fronteers“ konferencijoje Alexas Russellas pristatė interneto komponentus. Tačiau pastaruosius metus ar dvejus internetinių komponentų postūmis tikrai išaugo. Kaip tokia, specifikacijoje vis dar yra daug neramumų. Pavyzdžiui, atsisakyta HTML importavimo, nors dauguma dokumentų / šaltinių vis dar nurodo juos.

Testavimas

Vietinių žiniatinklio komponentų testavimui nėra daug specialių išteklių. Yra keletas perspektyvių įrankių, tokių kaip „skatejs ssr“ ir žiniatinklio komponentų testeris iš „Polymer“. Tačiau šie įrankiai iš tikrųjų skirti naudoti su atitinkamomis bibliotekomis. Tai kelia tam tikrų sunkumų naudojant vietinius žiniatinklio komponentus.

Pokyčių aptikimas

Neįtikėtina turėti pagrindinę sistemą, kuri automatiškai palaiko vaizdą sinchronizuotame su duomenų modeliu. Tai pirmiausia patraukė daugelį kampinių ir kitų rėmų.

Laikyti būseną sinchronizuojant su vaizdu nėra taip sunku mažu mastu. Bet tai gali labai greitai nebekontroliuoti, ir jūs įtraukiate daugybę renginių klausytojų ir užklausų parinkėjų.

Šešėlis DOM

Mane tikrai drasko šešėlis DOM. Viena vertus, man patinka kapsuliavimo idėja. Tai yra protingas dizaino modelis, kuris leidžia jūsų stiliaus kaskadą lengviau valdyti, supaprastina jūsų rūpesčius ir pan. Tačiau tai taip pat kelia problemų, kai norite, kad tam tikri dalykai prasiskverbtų per tą kapsulę (pvz., Bendro stiliaus lapą), ir vyksta diskusijos apie geriausią būdą tai padaryti.

DOM struktūrų generavimas

Dalis rėmų / bibliotekų, tokių kaip „Angular“ ir „React“, didybės yra ta, kad jie yra savo DOMain'o valdovai. Tai reiškia, kad jie puikiai efektyviai perteikia ir perteikia struktūras DOM. Iš „Angular University“ tinklaraščio:

„Angular“ nekuria HTML, o tada perduoda jį naršyklei, kad jis būtų išanalizuotas, o „Angular“ tiesiogiai generuoja DOM duomenų struktūras!

Pavyzdžiui, kampinis, skirtingai nei „jQuery“, tiesiogiai atkuria DOM duomenų struktūras. Tai yra, užuot perduodant HTML naršyklei, kad jis būtų išanalizuotas, o tada pateiktas į DOM duomenų struktūras. Tai labiau veikia, nes pašalina tą analizavimo veiksmą. Virtualusis DOM taip pat yra gana naudingas, nes jie neleidžia iš naujo pateikti informacijos kiekvieną kartą, kai reikia atnaujinti rodinį.

Argumentai "už"

Kita vertus, tokiu būdu kuriant programas yra keletas neabejotinų pranašumų:

Paketo dydis

Galutinis produktas gali būti (dėmesio CAN ), todėl daug mažesni ir labiau kompaktiškas nei kas nors sukurta moderni sistema. Pvz., Mano sukurtos receptų programos paskutinė versija buvo mažesnė nei pusė naujos „Kampinio“ versijos dydžio.

Pastaba: tai atnaujinti, optimizuoti rinkinių dydžiai.

Supratimas

Jei iš tikrųjų kūrėte tik su sistema ir jos CLI, tai gali būti puikus pratimas sukurti žiniatinklio programą be papildomų įrankių. Kaip asmeniui, norinčiam pasiekti tam tikrą žiniatinklio kūrimo meistriškumo lygį (kiek tai įmanoma), man buvo būtina įgyti daugiau praktinės patirties naudojant kūrimo įrankius, naršyklės API, dizaino modelius ir kt.

Spektaklis

Nuostabu tai, ką daro šios „front end“ sistemos ir bibliotekos užkulisiuose. Tačiau galite sumokėti našumo kainą, jei nuspręsite naudoti bet kurį iš jų; nemokamų pietų nėra. Yra daugybė potencialių naikinimo galimybių: ar tai būtų švaistomi perdarymai, nereikalingi klausytojai, gilus objektų palyginimas, ar nereikalingos ir didelės DOM manipuliacijos. Čia galite iškirpti daug sudėtingumo, įgyvendindami viską nuo nulio.

Kampinis ir reaguoti komandos atrodo žino šiuos spąstus, ir pateikė tokius dalykus kaip shouldUpdate metodas keitimais ir onPush ChangeDetection kaip toliau optimizuoti veiklos priemonėmis.

Paprastumas ir kodo nuosavybė

Jūs rizikuojate, kai įvedate trečiosios šalies kodą. Ši rizika sumažėja naudojant patikrintas bibliotekas / sistemas, tačiau niekada nėra pašalinta. Jei patys ar su savo komanda galite išsisukti rašydami kodą, galite sumažinti šią riziką ir išlaikyti kodinę bazę, kurią pažįstate ir iš jos.

Užrašai ir įdomios smulkmenos

Turėjau sprogimą dirbdamas su „Parcel“. Kartais jautėsi šiek tiek ribotesnis nei „Webpack“, kai bandžiau išspręsti tam tikrus krašto atvejus, tačiau radau, kad „nulinės konfigūracijos“ žymos eilutė iš esmės atitinka tiesą.

Man taip pat aišku, kad daugelis „React“ pažymi „biblioteka“, o „Vue“ - „progresyvia“ sistema. Nors suprantu to priežastis, manau, kad „React“, „Vue and Angular“ išsprendžia daugybę tų pačių problemų. Taigi aš juos visus svarstau kartu su sąvoka „pagrindai“.

Kodėl gi nenaudojant trafareto ar polimero? Norėjau kiek įmanoma vengti paketų, bibliotekų ir sistemų naudojimo. Norėjau sužinoti, kiek interneto standartai pakilo, kad atitiktų šiuolaikinę plėtrą (išskyrus kūrimo įrankius).

Esu tikras, kad yra daugybė kitų būdų, kaip sukurti SPA ar „front end“ programą be pagrindinės sistemos ar bibliotekos. Aš čia išbandžiau vieną būdą ir norėčiau išgirsti apie kitus!

Santrauka

Puikus euristinis sprendimas naudoti ar nenaudoti sistemą yra tai, ką aš vadinu „lūžio tašku“. Augant jūsų programai ateina taškas, kuriame jūs sukursite savo sistemą, kad galėtumėte pakartotinai naudoti funkcionalumą ir struktūrą. Pvz., Turite daugybę formų ir norite sukurti pakartotinai naudojamą logiką pakartotiniam tikrinimui.

Jei atsidursite šioje vietoje, turite nuspręsti, ar verta investuoti laiką į sistemų kūrimą, kad pasiektumėte tai, ką galite greitai pasiekti naudodami sistemą ar biblioteką. Priklausys nuo jūsų laiko apribojimų ar biudžeto apribojimų, bus skirtingi taškai, tačiau sistemos vis tiek yra labai aktualios, atsižvelgiant į tinkamus scenarijus.

Be to, daugelį to, ką daro sistemos, greičiausiai bus lengviau padaryti su mažesnėmis bibliotekomis ir (arba) vietiniu kodu, kai laikas eis. Paimkime mano paraišką kaip pavyzdį. Tuo pačiu metu, jei didelės sistemos ir bibliotekos išliks universalios, jos gali morfuoti, prisitaikyti ir laikytis. Jei ne, jie gali baigtis kaip „jQuery“ - daugumos praeities įrankiu.

Išvada

Apibendrinant galima pasakyti, kad yra daug žadančių būdų kurti sudėtingas „front end“ programas be sistemų. Tačiau tokių dalykų, kaip interneto komponentai, specifikacijos vis dar keičiasi ir yra tam tikrų spragų. Sistemos vis dar daro daug nuostabių dalykų ir gali labai palengvinti plėtrą.

Šiuo metu, kiek galiu pasakyti, sistemos naudos privalumai dažnai nusveria minusus. Tačiau jei sistemos nepradės spręsti naujų problemų ir toliau vystysis, jos ilgainiui išnyks.

Ištekliai

Kampinis pradedančiųjų vadovas: kodėl kampinis? Pagrindiniai privalumai

Pastaba: Šis įrašas yra nuolatinės „Kampinis pradedantiesiems“ serijos dalis, čia yra visa serija: Kampinis pradedantiesiems ... blog.angular-university.io Palyginimas su kitomis sistemomis - Vue.js

„Vue.js“ - „Progressive JavaScript Framework“ vuejs.org našumo optimizavimas - reakcija

Viduje „React“ naudoja keletą sumanių metodų, kad sumažintų brangių DOM operacijų, reikalingų atnaujinti ... reakjs.org žiniatinklio komponentus, skaičių.

Kaip kūrėjai, visi žinome, kad kuo daugiau pakartotinai naudoti kodą yra gera idėja. Tradiciškai taip nebuvo ... developer.mozilla.org Giliausia priežastis, kodėl egzistuoja šiuolaikinės „JavaScript“ sistemos

Mačiau daug daug žmonių, kurie aklai naudojasi modernia sistema, pavyzdžiui, „React“, „Angular“ ar „Vue.js“. Šios sistemos teikia ... medium.com Interneto komponentų formavimas naudojant bendro stiliaus lapą

Žiniatinklio komponentai yra nuostabi nauja žiniatinklio funkcija, leidžianti kūrėjams apibrėžti savo pasirinktinius HTML elementus ... www.smashingmagazine.com