Redaktørens merknad: Ember.js-teamet har skiftet til en fremskyndet utgivelsesplan og fra denne utgivelsesdatoen er det på versjon 1.2.0. Denne opplæringen ble skrevet pre-v1.0, men mange av konseptene er fortsatt aktuelt. Vi gjør vårt beste for å utføre rettidig innhold og disse situasjonene skje fra tid til annen. Vi vil arbeide for å oppdatere dette i fremtiden.
I del 3 av min Ember-serie viste jeg deg hvordan du kan samhandle med data ved hjelp av Embers Ember.Object
hovedbasen for å lage objekter som definerer metodene og egenskapene som fungerer som en wrapper for dine data. Her er et eksempel:
App.Item = Ember.Object.extend (); App.Item.reopenClass (all: function () return $ .getJSON ('http://api.ihackernews.com/page?format=jsonp&callback=?') .Then (funksjon (svar) var items = [ ]; response.items.forEach (funksjon (item) items.push (App.Item.create (item));); returnere elementer;);
I denne koden er vi underklasse Ember.Object
bruker "forlenge()
"og opprett en brukerdefinert metode kalt"alle()
"som gjør en forespørsel til Hacker News for JSON-formaterte resultater av sin nyhetsfeed.
Selv om denne metoden definitivt virker og fremdeles fremmes av Ember-based Discourse som deres måte å gjøre det, krever det det du kutte ut og avslør API-en som du vil referere til dataene med. De fleste MVC-rammer har en tendens til å inkludere ORM-lignende evner, så hvis du er vant til Rails, vil du for eksempel være godt kjent med fordelene med ActiveRecord som bidrar til å håndtere og gjøre den tunge løftingen av å interagere med data.
Ember-teamet har ønsket å gjøre det samme, men deres hovedfokus har vært å få en stabil v1-utgivelse av deres kjerneramme først for å sikre at komplementære komponenter kan bygges på et stabilt fundament. Jeg applauderer faktisk dette, og jeg har faktisk nevnt det faktum at du bør holde av med å bruke Ember Data på grunn av dette.
Nå som Ember RC8 er ute og v1 synes å komme rundt hjørnet, følte jeg det var en god tid å begynne å utforske Ember Data og se hva det tilbyr.
Det første jeg vil understreke er at Ember Data er et pågående arbeid, og på samme måte som Ember startet, vil det nok se flere API-endringer i løpet av de neste månedene. Selv om det ikke er ideelt, er det viktig å begynne å se på hvordan du vil strukturere appene dine ved hjelp av biblioteket. For å gi deg en god beskrivelse av hva Ember Data gir, har jeg kopiert i den velskrevne beskrivelsen fra GitHub-siden:
Ember Data er et bibliotek for lasting av data fra et persistenslag (for eksempel en JSON API), kartlegging av disse dataene til et sett med modeller i klientprogrammet ditt, oppdatering av disse modellene, og lagring av endringene tilbake til et vedvarende lag. Den gir mange av fasilitetene du finner i server-side ORMer som ActiveRecord, men er designet spesielt for det unike miljøet til JavaScript i nettleseren.
Så som jeg nevnte, er det ment å trekke ut mye av kompleksiteten ved å jobbe med data.
Hvis du har lest mine tidligere opplæringsprogrammer, bør du være veldig kjent med hvordan du setter opp en side for å utnytte Ember. Hvis du ikke har gjort det, bør du gå til Ember.js hjemmeside og ta tak i startpakken. Du finner den midt i siden som den vises med en stor knapp. Dette gir deg den mest oppdaterte versjonen av Ember som du trenger for å kunne jobbe med Ember Data. Den enkleste måten å få en nedlastbar versjon av Ember Data på er å gå til API docs for modeller
, bla til bunnen og last ned biblioteket. I tillegg kan du gå til bygger
side for å trekke ned de nyeste byggene av ethvert Ember-relatert bibliotek.
Legge til Ember Data er like enkelt som å legge til en annen JavaScript-fil i blandingen slik:
Dette gir deg nå tilgang til Ember Data objekter, metode og egenskaper.
Uten noen konfigurasjon kan Ember Data laste og lagre poster og relasjoner servert via en RESTful JSON API, forutsatt at det følger visse konvensjoner.
Ember bruker et spesielt objekt som heter a butikk
å laste modeller og hente data og er basert på Ember DS.Store
klasse. Slik definerer du en ny butikk:
App.Store = DS.Store.extend (...);
Hvis du husker fra mine tidligere artikler, "App"
er bare et navneområde opprettet for programnivå, objekter, metoder og egenskaper for applikasjonen. Selv om det ikke er et reservert ord i Ember, vil jeg oppfordre deg til å bruke samme navn som nesten hver opplæring og demo jeg har sett, bruker den til konsistens.
Butikken du lager, holder de modellene du lager, og vil fungere som grensesnittet med serveren du definerer i adapteren. Som standard oppretter og knytter Ember Data til butikken din en REST-adapter basert på DS.RestAdapter
klasse. Hvis du bare definerte koden ovenfor, ville du ha en adapter som er tilknyttet den som standard. Ember magi på sitt beste. Du kan også bruke en Fixture-adapter også hvis du jobber med data i minnet (for eksempel JSON du laster fra kode), men siden dette handler om å lage API-anrop, er REST-adapteren mer passende.
Du kan også definere din egen adapter for de situasjonene der du trenger mer tilpasset kontroll over grensesnitt med en server ved å bruke adapter
eiendom i butikkdeklarasjonen din:
App.Store = DS.Store.extend (adapter: 'App.MyCustomAdapter');
Koden jeg oppførte på toppen av denne opplæringen var et eksempel på hvordan du bruker Ember.Object
å lage modellene for din søknad. Ting endres litt når du definerer modeller via Ember Data. Ember Data gir et annet objekt som heter DS.Model
som du underklasse for hver modell du vil opprette. For eksempel tar du koden ovenfra:
App.Item = Ember.Object.extend ();
Det vil nå se slik ut:
App.Item = DS.Model.Extend ()
Ikke så stor forskjell når det gjelder utseende, men en stor forskjell når det gjelder funksjonalitet, siden du nå har tilgang til REST-adapterens evner, samt Ember Datas innebygde relasjoner som en-til-en, en til mange og mer. Hovedfordelen er imidlertid at Ember Data gir krokene for å samhandle med dataene dine via modellene dine i motsetning til at du må rulle din egen. Henvisning til koden fra oven på nytt:
App.Item.reopenClass (all: function () return $ .getJSON ('http://api.ihackernews.com/page?format=jsonp&callback=?') .Then (funksjon (svar) var items = [ ]; response.items.forEach (funksjon (element) items.push (App.Item.create (item));); returnere elementer; );
Mens jeg måtte lage min egen metode for å returnere alle resultatene fra mitt JSON-anrop, gir Ember Data en finne()
metode som gjør akkurat dette og tjener også til å filtrere ned resultatene. Så alt i alt, alt jeg trenger å gjøre er å ringe følgende samtale for å returnere alle mine poster:
App.Item.find ();
De finne()
Metoden vil sende en Ajax-forespørsel til URL-adressen.
Dette er akkurat det som tiltrekker så mange utviklere til Ember; forethought gitt til å gjøre ting enklere.
En ting å huske på er at det er viktig å definere i egenskapen de attributter du planlegger å bruke senere i modellen (for eksempel i maler). Dette er lett å gjøre:
App.Post = DS.Model.extend (tittel: DS.attr ('string'));
I min demo-app vil jeg bruke tittelegenskapen returnert via JSON, slik at du bruker attr ()
metode, angi hvilke attributter en modell har til min disposisjon.
En ting jeg vil nevne er at Ember Data er utrolig kresen om strukturen til JSON returnerte. Fordi Ember utnytter katalogstrukturer for å identifisere bestemte deler av applikasjonene dine (husk navnekonvensjonene vi diskuterte i min første Ember-artikkel?), Gjør det visse forutsetninger om hvordan JSON-dataene er strukturert. Det krever at det er en navngitt rot som vil bli brukt til å identifisere dataene som skal returneres. Her er hva jeg mener:
'posts': ['id': 1, 'title': 'En venn av meg har nettopp skrevet dette.', 'url': 'http://i.imgur.com/9pw20NY.jpg'] [js]Hvis du hadde definert det slik:
[js] 'id': '1', 'title': 'En venn av meg har nettopp skrevet dette.', 'url': 'http://i.imgur.com/9pw20NY.jpg', 'id': '2', 'title': 'En venn av meg har bare postet dette.', 'url': 'http://i.imgur.com/9pw20NY.jpg',
Ember Data ville ha helt balked og kastet følgende feil:
Serveren din returnerte en hash med nøkkel-ID, men du har ingen kartlegging for den.
Årsaken er at siden modellen heter "App.Post"
, Ember Data forventer å finne en URL kalt "innlegg" hvorfra den vil trekke dataene fra. Så hvis jeg definerte butikken min som sådan:
App.Store = DS.Store.extend (url: 'http: //emberdata.local');
og min modell som dette:
App.Post = DS.Model.extend (tittel: DS.attr ('string'));
Ember Data antar at Ajax-forespørselen fra finne()
metoden vil se slik ut:
http: //emberdata.local/posts
Og hvis du gjorde en forespørsel om en bestemt ID (som å finne (12)), ville det se slik ut:
http: //emberdata.local/posts/12
Dette problemet kjørte meg bra, men å gjøre et søk fant mange diskusjoner om det. Hvis du ikke kan konfigurere JSON-resultatene dine på denne måten, må du opprette en tilpasset adapter for å massere resultatene, slik at de seriøst serialiseres før de kan bruke den. Jeg dekker ikke det her, men planlegger å utforske mer av det snart.
Jeg ønsket med vilje å holde denne opplæringen enkel fordi jeg vet at Ember Data er i endring, og jeg ville gi en kort oversikt over hva den ga. Så jeg pisket opp en rask demo-app som bruker Ember Data til å trekke JSON-data fra min egen lokale server. La oss se på koden.
Først oppretter jeg søknadsnavnet mitt (som du ville gjøre for noen Ember-apper):
// Opprett vår Application App = Ember.Application.create ();
Deretter definerer jeg datalageret mitt og jeg erklærer url
fra hvor modellen vil trekke dataene fra:
App.Store = DS.Store.extend (url: 'http: //emberdata.local';);
I modellen angir jeg attributtet: tittel
, som jeg skal bruke i min mal senere:
// Vår modell App.Post = DS.Model.extend (tittel: DS.attr ('string'));
Til slutt forbinder jeg modellen til ruten via modellkroken. Legg merke til at jeg bruker den forhåndsdefinerte Ember Data-metoden finne()
å straks trekke tilbake JSON-dataene mine så snart appen er startet:
// Vår standard rute. App.IndexRoute = Ember.Route.extend (modell: funksjon () return App.Post.find (););
I malen for rotsiden (indeks) bruker jeg #Hver
Handlebars Directive å se gjennom resultatene av mine JSON data og gjengi tittelen på hvert av mine innlegg:
Det er det! Ingen Ajax ring for å lage eller spesielle metoder for å jobbe med dataene mine. Ember Data tok seg av å lage XHR-samtalen og lagre dataene.
Nå er dette utrolig forenklet, og jeg vil ikke lede deg til å tro at det er alle enhjørninger og valphunder. Da jeg gikk gjennom prosessen med å jobbe med Ember Data, fant jeg meg selv å ønske å gå tilbake til å bruke Ember.Object
hvor jeg hadde mer kontroll. Men jeg skjønner også at mye arbeid foregår for å forbedre Ember Data, spesielt i den måten det håndterer ulike datasultater. Så det er viktig å minst starte prosessen med å forstå hvordan denne tingen fungerer og til og med tilby konstruktiv tilbakemelding til teamet.
Så jeg oppfordrer deg til å hoppe inn og begynne å tinker med det, spesielt de som har en veldig sterk ORM-bakgrunn og kan bidra til å forme retningen til Ember Data. Nå er det beste tidspunktet å gjøre det.