Sisu
- Mis komponent on?
- Kapseldamine: ülevaade
- Üks kord, kui ma saan kasutada hiiglaslikke roboteid tehnilise metafoorina
- Mõte selles kõiges
- IFraamid
- Plussid
- Miinused
- Sujuvad iframes
- Plussid
- Miinused
- Veebikomponendid
- Shadow DOM
- Kohandatud elemendid ja HTML-mallid
- Plussid
- Miinused
- X-sildid: kohandatud elemendid polülib
- Plussid
- Miinused
- Järeldus
- Edasised ressursid
- Meeldis see? Loe neid!
Ehitades üha keerukamaks muutuvaid veebirakendusi, peame oma arendustavasid suurendama, et hakkama saada üha suurema hulga tehniliste võlgadega. Meie kirjutatav kood peaks olema modulaarne, korduvkasutatav ja kapseldatud, et vältida tihedalt ühendatud rakendusi. Monoliidid on iga arendaja jaoks aeganõudvad ja tülikad.
Esiosa arendajatena oleme JavaScripti koodi hallatavaks ja kapseldatuks hoidmiseks kasutanud objektikonstruktorite ja moodulite mustreid. Kuid on aeg, et meil oleks mingil viisil DOM-i osi kapseldada, nii et meil pole kokkupõrkeid ja tahtmatut suhtlemist.
Brauseri müüjad töötavad API-de kallal, mis võimaldavad meil luua brauserisse paremini kapseldatud komponente. Kui arendate rakendust, millel on ühel lehel palju funktsioone, või rakendust, mis tugineb paljudele kolmanda osapoole koodidele, ei saa kapseldamine teie jaoks piisavalt kiiresti tulla.
Mis komponent on?
"Parim, mida tarkvara kohta öelda saab, on see, et see on liiga väike." - James Halliday, JSConfEU 2012 koodikollaažist
Komponent on meie siinsetel eesmärkidel väike tarkvara, mis teeb ühte asja hästi. Komponent peaks sisaldama kõiki sobivaid tükke, mida ta oma töö tegemiseks vajab, ei rohkem ega vähem. Me võtame minimalismi omaks nii palju kui võimalik iga komponendi jaoks, kui me ei ohverda selle põhikäitumist ja struktuuri. Eesosa komponent peaks sisaldama kogu HTML-i, CSS-i ja JavaScripti, mis on vajalik barebone'i rakendamiseks, mida see peaks tegema.
Võite küsida endalt, miks meie praegune lähenemine jQuery kasutajaliidese või ExtJS-i kasutamisel ei ole piisav. Need on moodulkomponentide teegid, mis on juba lahendanud meie vajaduse nende korduvkasutatavate koodide ehitusplokkide järele. Kahjuks puudub neil üks asi, mida me vajame, et vältida selliseid probleeme nagu nimeruumi kokkupõrked ja ebamugav CSS-i spetsiifika, kui lisame oma rakendusse üha keerulisema.
Need meetodid süstivad lehele koodi vajaduse korral, kuid seda koodi ei kapseldata. Paljud hästi kirjutatud raamatukogud on rakendatud nii, et see pole asi, mille pärast olete pidanud muretsema. Kuid need pole lollikindlad. Kapseldamise sisseviimine DOM-i võib asja veelgi paremaks muuta.
Kapseldamine: ülevaade
Koodipõhiselt kapseldatakse objekt, kui see paljastab piiratud avaliku liidese teiste koodidega suhtlemiseks, samas kui selle andmed ja rakenduse üksikasjad on privaatsed. Lubage mul seletada hiiglaslike robotite abil.
Üks kord, kui ma saan kasutada hiiglaslikke roboteid tehnilise metafoorina
Keegi mäletab Mighty Morphin ’Power Rangereid? Nad olid maskeeritud superkangelased, kes võitlesid hiiglaslike soomusrobotitega kurjade jõudude vastu. Igal Power Rangeril oli oma robot, millel oli oma sisemine töö; oma piloot ja oma sisemine olek, millest teadis ainult tema. Vaenlasele viimase löögi andmiseks ühendaksid Power Rangers kõik robotid palju suuremaks robotiks nimega Megazord.
Ühendatuna saaksid komponendirobotid oma pilootide kaudu tõhusalt liituda ühiskasutatava käsujaama kaudu, ilma et iga robot sisemist tööd üksteisele avaldaks. Iga metsavahi roboti kohta võiks öelda, et see on kapseldatud; igaüks neist oli suurema terviku, nimega Megazord, komponent, mis pani tõsise tagumiku pihta.
Mõte selles kõiges
Kergesti hooldatavate rakenduste kirjutamiseks tuleks meie eesseadme kood jaotada väikesteks komponentideks, mis teevad vaid ühe väikese funktsiooni tõesti hästi. Peale selle tahame, et saaksime oma koodi lehel kasutada, riskimata nimeruumi kokkupõrgetega või CSS-valija tallamisega. Tugevate rakenduste loomiseks soovime, et meie komponendid oleksid kapseldatud, ja seni pole meil olnud brauseris DOM-iga väga häid viise. Jaotame 2013. aastal alustades meile saadaolevad võimalused.
IFraamid
iframe src = "http://hello-old-friend.com"> / iframe>
Alles hiljuti olid arendajate käsutuses ainsad tõeliselt kapseldatud elemendid iframe’id. Komponentide valmistamisel on iframe'i kasutamisel palju probleeme: need ei laiene sisule sobivaks, sisu visuaalsed kaunistused ei saa raamiga kattuda - loendit saab jätkata. Samuti on iframe aeglane.
Disquse kirjutatud kommentaaride tarkvara kasutab iframe'i, et kuvada antud dokumendi kommentaare. Kui logite Disqusisse sisse selle iframe'is, ei saa vanemveebisait juurdepääsu teie logiteabele. Teie käepigistus kommentaari jätmiseks on ainult teie ja Disquse vahel ning sellel pole midagi pistmist vanema veebilehega, kuhu kommentaari jätate. Vaadake Disqusega lehte ja näete.
Plussid
- Hea olukordades, kus soovite oma kasutajatele rohkem turvalisust
- Rakendatud kõigis stabiilsetes brauserikanalites
- Takistab JavaScripti konflikte teie peamise DOM-i skriptide ja iframe'i / komponendi vahel
- Saab laadida sisu muust domeenist kui teie rakendus on majutatud
Miinused
- Ärge laiendage sisu mahutamiseks
- Hüperlingid saavad navigeerida ainult iframe'i sisemuses, mitte vanemkontekstis
- Iframe'i elementide visuaalne kaunistamine ei saa iframe'i piiridega kattuda
- IF-raamid on aeglased. Üks lehel ja teil on kõik korras, kuid sellest hoolimata on probleeme
IFrame'id võivad pakkuda teatud turvalisust ja võimaldada hõlpsasti domeenivälise sisu laadimist, kuid peale selle ei ole vanilje iframe'id minu komponentide valmistamise esimene valik.
Sujuvad iframes
iframe õmblusteta src = "http://parent.com"> / iframe>
Kui hakkasin DOM-i kapseldamise võimalikke meetodeid põhjalikumalt uurima, olin veendunud, et uuemad meetodid hakkavad iframe'i trumpama ja et iframe'id närbuvad lõpuks võimaliku amortisatsiooni ja ebaselgusena.
Siis sujuv atribuut sattus minu radarile ja ma pidin oma positsiooni ümber mõtlema. Tundub, et iframe'id võivad selle probleemse domeeni eesmärgi saavutamiseks kinni jääda.
See atribuut muudab iframe'i käitumist mitmel viisil. CSS-reeglid saavad kaskaadida iframe'i kaudu, hüperlingid navigeerivad automaatselt vanema DOM-i kontekstis ja iframe suurendab automaatselt enda sisu piiravat kasti.
Kõlab hästi, eks? Saadame selle kohe tootmisse! Ah, välja arvatud see, et see atribuut on nii uus, et ükski stabiilne brauserikanal pole seda rakendanud. Kui aga haarate Chrome Canary koopia, saate sellega mängida. Võib kuluda mõni aeg, enne kui näeme seda omadust stabiilses kanalis, kuid hoidke silmad selle ees lahti.
Plussid
- Suurepärane, kui soovite lisada mõne funktsionaalsuse ja soovite, et vanema ulatusega funktsioonid ja stiilid seguneksid
- HTML-lingid toimivad vanemkontekstis
- Suuruse muutmine, sisemine loodus muudab paindliku stiili
Miinused
- Pole rakendatud üheski stabiilses brauserikanalis. Katsetamiseks peab teil olema Chrome Canary.
- Käitumine just nii, nagu see on võimalik, kuid selle parandamiseks võib kuluda aega
Veebikomponendid
Samal ajal kui iframe'i uuesti leiutamine on toimunud, on väravate ette ootamas uus väljakutsuja: veebikomponendid. Nimi kõlab küll üldsõnaliselt, kuid selles kontekstis viitab see paarile W3C spetsifikatsioonidele, et standardida brauserikäitumist kapseldatud komponentide jaoks Shadow DOM ja Kohandatud elemendid.
Shadow DOM
Uus Shadow DOM API annab arendajatele võimaluse lisada täieõiguslik DOM hostielemendi sisse. Peaksite sellele mõtlema põhimõtteliselt nagu HTML-elemendi sisse peidetud väike DOM, mille otsustate teie, arendaja, sisse panna. Varju DOM-i renderdamine asendab hostielemendi laste renderdamist. Saate hosti renderdamise täielikult asendada, kuid kui sellel on lapsi, võite kasutada spetsiaalset HTML-märgendit sisu> nende sisestamiseks.
Haarake Chrome Canary koopia ja proovige mängida järgmisega:
(Nõuanne: kui olete Kanaari saarte käivitanud, lubage veebiinspektoris valik „Show Shadow DOM”!)
div> Lihtsalt tavaline märgistus, siin pole midagi näha ... / div>
skript>
var innocentHost = document.querySelector (’div’);
var deviousShadow = innocentHost.webkitCreateShadowRoot (); // Kui see rida on täidetud ja varjuur on loodud, ilmub innocentHost tühjaks, kuna selle renderdamine asendatakse deviousShadow renderdamisega
deviousShadow.innerHTML = "h1> Boo! / h1>"; // Nii et anname DeviousShadow'ile sisu renderdamiseks. Aga mis siis, kui me tahame, et algne teksti sisu tuleks tagasi?
deviousShadow.innerHTML = "h1> Boo! / h1> content> / content>"; // Kasutame märgendit content>, et brauser käskida hostide lapsed sisestada
/ skript>
Kui lisate a vali atribuut Euroopa sisu> märgendiga saate oma hostelemendi laste klasside või ID-de abil isegi määrata, kus konkreetne hosti sisu ilmub.
See spetsiaalne DOM on kapseldatud selle vanema DOM-i ulatusest. Selle sisu ei mõjuta vanema ulatusega CSS ja JavaScript, kui te pole lipud spetsiaalselt määranud.
Kohandatud elemendid ja HTML-mallid
Kohandatud elemendid kasutades uut element> ja mall> siltide abil deklareerime sellise komponendi oma HTML-failis:
elemendi nimi = "mobile-nav" extends = "ul">
mall>
sisu> / sisu>
sisu select = "some-host-child"> / content>
/ mall>
/ element>
Seejärel saame kasutada kohandatud elementi, lisades oma päisesse HTML-malli ja rakendades hostelemendile atribuudi:
ul on = "mobile-nav">
li> Navigeerimine 1 / li>
li> Navigeerimine 2 / li>
li> Võtke meiega ühendust / li>
li> Avaleht / li>
/ ul>
Alati kui mall> silt renderdatakse, luuakse ja lisatakse Shadow DOM, et kohandatud elemendi sisemine toiming oleks kapseldatud. Tulemuseks on see, et kasutaja näeb algse hosti laste asemel renderdatuna järgmist:
- Sisestatud meie malli poolt!
- Kodu
- Navigeerimine 1
- Navigeerimine 2
- Võta meiega ühendust
Pange tähele, et kui kontrollite seda märgistust eelmises näites Chrome Canary Chrome'i arendaja tööriistadega, siis seda ka teete mitte vaata varjupuud, toon siin hüpoteetilise näite neile, kes seda artiklit serva vabastamise brauseris ei loe.
Alati kui mall> silt renderdatakse, luuakse ja lisatakse Shadow DOM, et kohandatud elemendi sisemine toiming oleks kapseldatud.
Shadow DOM + kohandatud elemendid == Veebikomponendid, unistav brauseri API, mille peame oma brauseris kapseldatud komponentide eesmärgi täitmiseks täitma. Pange tähele, et selle funktsiooni rakendamise kokkuleppimise eest vastutavad töögrupid arutavad selle kirjutamise ajal, kas kohandatud elemendid kasutavad atribuutimeetodit (üksikasjalikult kirjeldatud selles JSConfi EL-i videos) või loovad develoeprs täiesti kohandatud sildid see:
mobile-nav> / mobile-nav>
Mõlemal rakendamisel on erinevaid eeliseid ja vigu. Täpse teabe saamiseks ja otsuse ajakohasena jälgimiseks järgige seda Bugzilla piletit. Kipun eelistama kohandatud siltide süntaksit ja lähenemist põhjustel, mida olen eespool mainitud Bugzilla veas üksikasjalikumalt kirjeldanud.
Kui soovite samm-sammult läbi vaadata selliseid veebikomponentide näiteid nagu selles jaotises olevad, vaadake seda videot.
Plussid
- Kapseldatud komponendid, just need, mida me tahame!
- Seal on polüfill, et saaksime nendega mängida, kuid vajame siiski ka Chrome Canaryt
- Lihtne luua kasutajaliidese arendajatele
- Disaineritel on HTML-i siltidega lihtne deklaratiivselt kasutada
Miinused
- Pole rakendatud üheski stabiilses brauserikanalis. Katsed toimivad ainult Chrome Canary'is. Kuuldavasti järgib Firefox varsti pärast koostöölepingu sõlmimist selle rakendamise osas
- Mitme komponendi laadimine võib põhjustada lisakulusid, kui kasutate palju komponente, kuna igaüks neist on HTTP-päring (probleemi leevendamiseks võib HTML-malle siiski kokku liita)
X-sildid: kohandatud elemendid polülib
X-Tags on komponentide kogu ja register, mille on kokku pannud mõned Mozilla inimesed. See kasutab varjutatud DOM-i ja veebikomponentide tutvustamiseks atribuudimeetodi kohal kohandatud HTML-märgendi lähenemist.
Selle teegi kohandatud märgendi kasutamise süntaks võib olla nii lihtne:
x-panel src = "/ elements / demo / panel-content.html"> / x-panel>
X-Tagsil on uhke kena komponentide register, mida saate juba kasutada. Märgendi registreerimiseks ja sellega alustamiseks sündmuste haldamiseks peate tutvuma selle väga väikese API-ga aadressil x-tags.org.
See teek tundub sarnane teiste varem kasutatava kasutajaliidese komponentraamistikega, millega olete varem töötanud, välja arvatud see, et see pole üldse raamistik: võite oma registris olevaid komponente kasutada mis tahes viisil, ilma et oleksite keerukat hierarhiat sõltuvused; pole peidus ühtegi lisafunktsiooni, mida te ei vaja; pole üldotstarbelist raamatukogu paisumist, sest X-Tags on nutikas; see on ise komponent, kuna teeb lihtsalt ühte asja väga hästi; ja see võimaldab teil teha kohandatud komponente.
Lõpuks näib, et raamatukogu integreerib varju DOM-i ja veebikomponente, kui need spetsifikatsioonid lõpuks tahkuvad ja jõuavad peamistesse brauserikanalitesse.
Lõpuks kapseldumine? Loodan, et nii, sest siis võib see minu arendaja tööriistaketis mugavalt koha leida.
Plussid
- Kasutab lõpuks veebikomponenti ja varjutab DOM-i standardseid rakendusi, kui need on lõpuks kokku lepitud
- Tänapäeval kasutatav asustatud, organiseeritud mikromoodulite ökosüsteem
- Rakendus on väga barebones, et saaksite jääda vanill JavaScripti juurde
- Lihtne luua kasutajaliidese arendajatele
- Disaineritel on HTML-is deklaratiivselt lihtne kasutada
- Suurt rõhku brauseriteülesele ühilduvusele, eriti mobiilseadmetele
Miinused
- Päris kapseldamist veel pole. Kuid tundub, et arendajad rakendavad juba W3C spetsifikatsioonide põhjal ja seega peaksime eeldama, et vari DOM vastab sellele probleemile tulevikus
Järeldus
Kuna veebikomponendid ja parem kapseldamine leiavad tee meie töövoogu, eeldan, et näeme kliendipoolse eelistuse muutumist normiks. Kuigi kliendipoolne mallimine on juba populaarne viis funktsioone täis rakenduste loomiseks, võib suurema osa töö brauserisse mahalaadimine tähendada, et meil on eesmärkide saavutamiseks vähem traadi kaudu koodi.
See tegevus on eriti oluline, arvestades ebausaldusväärsete ja mõnikord ka aeglasemate mobiilsideühenduste kaudu allalaadimise mõju kasutajakogemusele. Kellegile ei meeldi aeglane veebirakendus.
Loodan, et varsti on minu käsutuses kohandatud siltidega tehtud komponentide tööriistakast. Kohandatud elementide korduvkasutatavuse ja lihtsa deklaratiivsuse tõttu saavad disainerid ja UX-i spetsialistid, kes pole programmeerimises tuttavad, kuid oskavad HTML-i, keerukamate kasutusjuhtumite prototüüpimiseks lihtsalt minu loodud kohandatud silte kasutades.
Ma ei eelda, et iga üldine vidin lahendab kõik funktsioonitaotlused kohe kastist, kuid kui peame kinni oma minimalistlikust komponendifilosoofiast, võime alustada millestki lihtsast ja lisada ainult vajaliku.
Sel aastal harjutage oma koodi kirjutama moodulisemalt ja jälgige nende uute brauserifunktsioonide arengut nende arendamisel. Te tänate ennast hiljem kõverast eesolemise eest.
Edasised ressursid
- Seal on video minu JSConfi EU talk Inspector Webist ja Shadow DOMi saladusest
- Shadow DOM 101 keskendub varju DOM-i põhijoonele: võimalusele sisu esitlusest eraldada
- Veebikomponentide seletaja annab teie üksikasjalikumad üksikasjad veebikomponentide kohta, millel on kõige vähem lühike keel, võrreldes teiste W3C dokumentidega
- TJ Holowaychuck selle kohta, mis on hea komponent, mida peaksite lugema (ja käivitas seejärel CommonJS-iga kasutatavate komponentide registri)
Sõnad: Angelina Fabbro
Angelina Fabbro on programmeerija, kes asub Kanadas Vancouveris ja töötab Steamclock Software'is. Angelinal on kognitiivteaduste taust, ta ehitab nutikaid roboteid ja uurib, millele inimesed tähelepanu pööravad. Tema kui veebiarendaja rekord on tasakaalus tänapäevase iOS-i kogemuse ja terava disainitajuga. Samuti õpetab ja juhendab Angelina Ladies Learning Code Vancouveri peatükki.
Kui ta ei räägi erinevatel üritustel programmeerimise teemadel,
Angelina säutsub kui @angelinamagnum ja kirjutab üle aadressil realityhacking.net.
Meeldis see? Loe neid!
- Rakenduse loomine
- Tasuta graffiti fontide valik
- Illustratori õpetused: hämmastavad ideed, mida täna proovida!
- Parim logode kujundamise ülim juhend
- Parimad tasuta veebifondid disaineritele
- Kasulikud ja inspireerivad flaierimallid
- 2013. aasta parimad 3D-filmid
- Vaadake, mis on liitreaalsuse järgmine
- Siin on see arendaja Ben Vinegari slaiditekk sujuvatel iframe'idel uuesti, juhul kui te seda vahele jätate
