Share
Det finnes mange JavaScript-biblioteker, og de fleste er veldig gode til å gi de tradisjonelle DOM-sentriske samhandlingene dine typiske nettsteder trenger. Men når det er på tide å bygge en håndterbar kodebase for en enkeltsidig app, er det her en hel rekke nye rammer kommer inn for å jevne ut ting.
Det gamle ordtaket er sant: "Bruk det beste verktøyet for oppgaven."
Det er ikke slik at tradisjonelle biblioteker som jQuery ikke kan hjelpe deg med å bygge opp desktop-lignende opplevelser, det er bare ikke brukskassen for det, og mangler ting som data-binding, hendelsesruting og statsadministrasjon. Selvfølgelig kan du sannsynligvis sammenkoble en mengde plugins for å oppnå noe av den funksjonaliteten, men etter å ha sett et rammeverk som er spesifikt bygget fra grunnen til å takle disse spesifikke problemene, mener jeg det er mer sanselig. Det gamle ordtaket er sant: "Bruk det beste verktøyet for oppgaven."
Jeg har nylig intervjuet med Ember.js-teamet; Det var motivert av mitt ønske om å bli kjent med hva jeg har kommet for å kalle "den nye hotness": Ember.js.
Ember passer til regningen for det jeg har beskrevet ovenfor, og gjør det på en måte som minner om mye hvordan jQuery tillater utviklere å komme raskt opp. Teamet har med vilje tatt skritt for å abstrahere mange av de kompleksitetene som er forbundet med å designe og bygge modell / View / Controller-baserte applikasjoner ved å bruke mange års kompetanse og kunnskap fra å bygge store applikasjoner.
Det jeg vil gjerne gjør er å få deg raskere med Ember.js, via en flerartet artikkelserie som gradvis vil introdusere deg til konseptene i rammen. Vi starter med den vanlige introen (som skjer for å være dette innlegget), og deretter gradvis rampe opp til å bygge en full søknad. Den store delen er at dette også vil hjelpe meg å styrke de konseptene jeg allerede har lært, og kanskje hente opp noen nye teknikker underveis! Jeg vil gjøre mitt beste for å få Ember.js-teamet til å vurdere dette materialet for nøyaktighet og kanskje til og med bidra med noen nuggets til det.
Før vi fortsetter, hodet opp: Ember.js gjør mye magi for deg. Det er tider når du ser på koden og sier "Huh? Hvordan gjorde det det?" Jeg har vært der, og jeg vil gjøre mitt beste for å destillere ting, men jeg kommer ikke til å dykke inn i Ember's rammekode. I stedet diskuterer jeg hvordan du kan utnytte sine verktøy og API for å bygge appen din.
Så la oss sparke dette.
Ember.js er ikke et rammeverk for å bygge tradisjonelle nettsteder.
Den første tingen å huske på er at Ember.js ikke er et rammeverk for å bygge tradisjonelle nettsteder. Biblioteker som jQuery og MooTools passer perfekt til det. Hvis du vurderer Ember.js, er antagelsen at du leter etter å bygge opp desktop-lignende opplevelser - spesielt skalerbare. Faktisk er slagordet for rammen "et rammeverk for utvikling av ambisiøse webapplikasjoner" som forteller deg at det er tydeligvis ikke pappaens JavaScript-bibliotek.
Jeg nevnte tidligere at Ember utnytter MVC-mønsteret for å fremme riktig kodehåndtering og organisering. Hvis du aldri har gjort MVC-basert utvikling, bør du definitivt lese på det. Nettuts + har en flott artikkel om emnet her. For de som er kjent med konseptene, bør du føle deg hjemme. Den eneste tingen jeg har hørt konsekvent er at det å gjøre skiftet fra Backbone til Ember.js faktisk er enkelt fordi Ember gjør mye av det tunge løftet for deg, samtidig som du opprettholder kodenes organisasjonsmønstre som disse utviklerne er vant til.
Ember er også avhengig av klientsiden maler ... a LOT. Det bruker håndteringsskjermbildet som gir uttrykk som lar deg lage dynamiske HTML-baserte maler. En Ember-utvikler kan binde data til disse innebygde uttrykkene og dynamisk endre visningen av appen deres på fly. For eksempel kan jeg opprette en mal som kan motta en rekke mennesker og vise dem i en uordnet liste:
Legg merke til "#each" -uttrykket som fungerer som loop-direktiv, oppsummering over hvert element i "folk" -arrayet og erstatte uttrykket name med en faktisk verdi. Det er viktig å merke seg at de dobbelte parentesene er tokens som brukes av håndtak for å identifisere uttrykk. Dette er et lite eksempel, og vi vil dykke inn i flere detaljer senere.
Handlebars er en utrolig kraftig klient-side templerende motor, og jeg vil anbefale å vurdere ikke bare Embers guider, men håndteringsnettstedet selv for å få full forståelse av tilgjengelige alternativer. Du bruker det ganske mye.
Ember.js er avhengig av flere biblioteker, så du må ta en kopi av jQuery og Handlebars. Men vent, sa jeg ikke at jQuery og Ember spilte i forskjellige rom? Vel, det gjorde jeg, men her er tingen: Ember-teamet handler om ikke å gjenoppfinne hjulet. De valgte jQuery å gjøre det som er best: jobbe med DOM. Og det er bra, siden jQuery er veldig bra på det. Det er også grunnen til at de gikk med håndtak, noe som er et utmerket templerende bibliotek som tilfeldigvis ble skrevet av Yehuda Katz, som er et Ember-kjerneamedlem.
Den enkleste måten å få de filene du trenger, er å gå til Ember.js Github repo og dra ned startpakken. Det er en kjele for deg å begynne med. På tidspunktet for denne skrivingen inneholder den:
Det er også en grunnleggende HTML-mal som er kodet for å inkludere alle tilknyttede biblioteker (jQuery, Ember, etc.) og sammen med et eksempel på en håndteringsmal og "app.js", som inneholder kode for å koble av en grunnleggende Ember-app.
Bare vær oppmerksom på at app.js ikke er en del av rammen. Det er en vanlig ole JavaScript-fil; du kan nevne alt du vil ha. Og mens vi bruker den til denne opplæringsserien, nedover veien, vil du sannsynligvis ende opp med å dele JavaScript inn i flere filer akkurat som du ville for noe annet nettsted eller en app. Også, Ember forventer ikke en bestemt katalogstruktur for rammafilene dine.
Når du ser på Starter Kit-koden, kan det se ut som den typiske nettstedskoden din. I noen henseender har du rett! Når vi begynner å organisere ting, skjønner du, hvordan å bygge en Ember-app er annerledes.
Før du begynner å hack på kode, er det viktig å forstå hvordan Ember.js fungerer, og at du groker de bevegelige delene som utgjør en Ember-app. La oss ta en titt på disse delene og hvordan de forholder seg til hverandre.
Maler er en viktig del av å definere brukergrensesnittet. Som jeg nevnte tidligere, er Handlebars klientsiden biblioteket som brukes i Ember og uttrykkene fra biblioteket brukes mye når du oppretter brukergrensesnittet for søknaden din. Her er et enkelt eksempel:
Legg merke til at uttrykkene er blandet inn i HTML-oppslaget ditt, og via Ember vil dynamisk endre innholdet som vises på siden. I dette tilfellet vil firstName og lastName plassholdere bli erstattet av data hentet fra appen.
Håndtak gir mye kraft, via en fleksibel API. Det vil være viktig for deg å forstå hva det tilbyr.
En applikasjons Router bidrar til å administrere tilstanden til applikasjonen.
En applikasjons Router bidrar til å administrere programtilstanden og ressursene som trengs når en bruker navigerer i appen. Dette kan omfatte oppgaver som for eksempel å be om data fra en modell, tilkobling av kontroller til visninger, eller visning av maler.
Du gjør dette ved å opprette en rute for bestemte steder i søknaden din. Ruter angir deler av programmet og nettadressene som er knyttet til dem. Nettadressen er nøkkelidentifikatoren som Ember bruker for å forstå hvilken applikasjonsstatus som skal presenteres for brukeren.
Accentsconagua
App.Router.map (funksjon () this.route ('about'); // Tar oss til "/ om"); Bevegelsen av en rute (for eksempel: forespørsel om data fra en modell) styres via forekomster av Ember-ruteobjektet og avfyres når en bruker navigerer til en bestemt nettadresse. Et eksempel ville være å be om data fra en modell, slik:
App.EmployeesRoute = Ember.Route.extend (modell: funksjon () return App.Employee.find (););
I dette tilfellet, når en bruker navigerer til "/ ansatte" -delen av søknaden, gjør ruten en forespørsel til modellen for en liste over alle ansatte.
En objektrepresentasjon av dataene.
Modeller er en objektrepresentasjon av dataene din søknad vil bruke. Det kan være et enkelt utvalg eller data dynamisk hentet fra en RESTful JSON API, via en Ajax-forespørsel. Ember Data-biblioteket tilbyr API for lasting, kartlegging og oppdatering av data til modeller i søknaden din.
Kontrollører brukes vanligvis til å lagre og representere modelldata og attributter. De fungerer som en proxy, som gir deg tilgang til modellens attributter og lar maler få tilgang til dem for å dynamisk gjengi skjermen. Det er derfor en mal vil alltid være koblet til en kontroller.
Det viktigste å huske er at mens en modell henter data, er en kontroller det du vil bruke til å programmere eksponere dataene til forskjellige deler av søknaden din. Selv om det ser ut til at modeller og kontrollere er tett koblet, har modeller seg selv ikke kjennskap til kontrollerne som vil bruke dem senere.
Du kan også lagre andre applikasjonsegenskaper som må fortsette, men trenger ikke å bli lagret på en server.
Visninger i Ember.js er ment å håndtere hendelser rundt brukerinteraksjon og oversette dem til hendelser som har betydning i søknaden din. Så hvis en bruker klikker på en knapp for å slette en ansatt, er visningen ansvarlig for å tolke den innfødte nettleserhendelsen og behandle den på riktig måte i sammenheng med søknadens nåværende tilstand.
En av måtene som Ember.js bidrar til å minimere mengden koden som trengs, og håndtere ting for deg bak kulissene, er gjennom navnekonvensjoner. Måten du definerer og navngir rutene dine (og ressursene) påvirker navnene på dine kontroller, modeller, visninger og maler. For eksempel, hvis jeg lager en rute, kalt "ansatte":
App.Router.map (funksjon () this.resource ('employees');); Jeg vil da nevne komponentene mine, slik:
Bruk av denne navngivningskonvensjonen tjener et dobbelt formål. For det første gir det deg et semantisk forhold mellom like komponenter. For det andre kan Ember automatisk opprette de nødvendige objekter som kanskje ikke eksisterer (for eksempel: et ruteobjekt eller en kontroller) og koble dem opp til bruk i din søknad. Dette er "magien" som jeg nevnte tidligere. Faktisk er dette spesifikt hva Ember gjør på det globale applikasjonsnivået, når du instantierer applikasjonsobjektet:
var App = Ember.Application.create ();
Den ene linjen oppretter standard referanser til programmets ruter, kontroller, visning og mal.
Når jeg går tilbake til den "ansatte" -ruten jeg opprettet ovenfor, vil det skje at når en bruker navigerer til "/ ansatte" i søknaden din, vil Ember lete etter følgende objekter:
Hvis den ikke finner dem, vil den opprette en forekomst av hver, men vil ikke gjengjøre noe, siden du ikke har spesifisert en modell for å utlede data fra eller en mal for å vise dataene med. Dette er grunnen til at navngivningskonvensjonen er så viktig. Det tillater Ember å vite hvordan man skal håndtere oppgavene knyttet til en bestemt rute, uten at du trenger å koble opp ting manuelt.
Legg merke til at i det første eksemplet brukte jeg singularnavnet, "Medarbeider", for å definere modellen. Det er med hensikt. Selve arten av navnet "Ansatte" dikterer at jeg kan jobbe med 0 til mange ansatte, så det er viktig å bygge en modell som gir fleksibilitet til å returnere en ansatt eller alle ansatte. Den enslige navngivningskonvensjonen til denne modellen er ikke et krav til Ember, da modeller selv ikke har kjennskap til kontrollerne som vil bruke dem senere. Så du har fleksibilitet i å navngi dem, men for konsistens vil det være enklere å håndtere koden din ved å holde fast ved denne konvensjonen.
Også, jeg valgte å bruke ressurs() Metode for å definere ruten min, fordi i dette scenariet, ville jeg mest sannsynlig ha nestede ruter for å administrere detaljsidesider for spesifikk ansattes informasjon. Vi snakker om hekking senere i serien.
Nøkkelfunksjonen er at ved å bruke en konsekvent navngivningssystem, kan Ember enkelt håndtere kroker som binder disse komponentene sammen uten at du trenger å eksplisitt definere forholdene via et ton kode.
Fullstendig informasjon om Embers navnekonvensjoner er gitt på prosjektets nettsted og er en må lese.
I neste del av serien vil vi dykke inn i koden for å danne grunnlag for vår søknad.
Vi har gått over kjernekonseptene til Ember og diskutert nøkkelhøye aspekter på rammen. I neste del av serien vil vi dykke inn i koden for å danne grunnlag for vår søknad. I mellomtiden vil jeg igjen anbefale at du begynner å se på dokumentasjonen for håndtak for å få en følelse av uttrykksekstaxen. Også, hvis du er virkelig chomping på litt for å komme inn i Ember, hold deg innstilt på Tuts + Premium, som snart vil tilby et fullt kurs som går deg gjennom å bygge en Ember-basert applikasjon!
Som jeg bemerket i begynnelsen av denne artikkelen, leder Ember.js Core Team Yehuda Katz og Tom Dale gjennom dette for nøyaktighet, og ga det tommelen opp. Ember team godkjent! Ser deg snart!
