Bruk Backbone.js for å øke interaksjonen

Forfatter: Monica Porter

Opprettelsesdato: 13 Mars 2021

Oppdater Dato: 1 Kan 2024

Bruk Backbone.js for å øke interaksjonen - Kreativ

Innhold

La oss komme i gang da
Vår første modell
En samling bilder
The FlickrBombImage
Utsiktslaget
FlickrBombImageView
Hjemmestrekningen
Fungerer bra med store ol nettapper også
Tilleggsressurser

Hvis du ønsker å raskt bygge et lite JavaScript-verktøy, tenker du sannsynligvis ikke på å bruke et rammeverk. Lettere å hacke sammen noen jQuery-koder i stedet for å installere og lære et nytt rammeverk, ikke sant? Feil, Backbone.js er et super lett limrammeverk som ser ut som det vanlige gamle JavaScript du pleide å skrive.

Vi gjør mange statiske prototyper her på ZURB, fordi vi liker å kunne klikke gjennom sider uten å måtte skrive noen backend-kode. Ofte dropper vi i dystre grå plassholderbilder, eller noen ganger ville vi søke i Flickr etter eksempler på bilder som hjalp oss med å visualisere hva som kan hende i det endelige utkastet. Det er til en magisk fredag, da vi bestemte oss for at det ville være fantastisk å skrive litt JavaScript for å løse våre problemer. Vi ønsket å kunne søke og velge bilder på Flickr, direkte fra selve plassholderbildene. Vi vil kalle det FlickrBomb, og dette er historien om hvordan vi bygde den ved hjelp av Backbone.js.

Det anbefales sterkt at du tar en rask titt på FlickrBomb før du leser. Det er en av disse tilbudene "et klikk er verdt tusen ord". Fortsett, vi venter.

Det er mange JavaScript-rammer på blokken i disse dager, SproutCore, JavaScriptMVC, Spine, Sammy, Knockout. Men vi likte Backbone.js for dette prosjektet av noen forskjellige grunner:

1. Det er lett (100% fettfritt faktisk)

i vekt, med den siste pakkede versjonen på omtrent 4,6 kb
i kode, som er litt over 1000 linjer med kode, er det ikke veldig vanskelig å følge en bunnspor ned i internene uten å miste tankene dine

2. Det ser ut som JavaScript

fordi det er JavaScript, er det alt og alt
den bruker jQuery, som til og med bestemoren din kjenner til i disse dager

3. Super enkel utholdenhet

ut av boksen fortsetter data til en backend (via REST), men ved å slippe inn en enkelt plugin vil den lagre til lokal lagring i stedet
fordi den trekker ut persistens-API-et, kan vi få det til å hvile til en REST-backend ved bare å fjerne den lokale lagringspluggen

La oss komme i gang da

Fordi Backbone.js bare er JavaScript, er alt vi trenger å gjøre å inkludere det sammen med Underscore.js på siden. jQuery er ikke en vanskelig avhengighet for Backbone i seg selv, men vi skal bruke den, så vi tar den med her. Vi kobler også opp den lokale lagringsprogrammet, siden vi ikke vil bry deg med å konfigurere en backend. Merk at koblet filene direkte her for enkelhets skyld, men du bør alltid være vert for dine egne eiendeler i produksjonen.

script src = "http://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js"> / script> script src = "http://documentcloud.github.com/backbone/ backbone-min.js "> / script> script src =" http://documentcloud.github.com/underscore/underscore-min.js "> / script> script src =" https://raw.github.com/ jeromegn / Backbone.localStorage / master / backbone.localStorage-min.js "> / script>

All følgende kode i denne artikkelen er spesifikk for applikasjonen vår, så vi kan inkludere den i en app.js-fil, eller bare innebygd hvis det er din ting. Bare husk å ta den med etter ryggraden. Backbone gjør det mulig å abstrakte deler av applikasjonen vår, for å gjøre dem begge modulære for enkel gjenbruk og mer lesbare for andre. For å illustrere den abstraksjonen best, skulle vi forklare utformingen av FlickrBomb fra bunnen og opp, startende med modellene og slutt med utsikten.

Vår første modell

Den første oppgaven skulle takle er å trekke bildene fra Flickr. Modellering av en FlickrImage i ryggraden er enkel nok, vi lager en ny modell kalt FlickrImage, og legger til noen metoder for å hjelpe oss med å få tommelen i forskjellige størrelser.

Modeller i Backbone er gjenstander som kan vedvares, og har noen funksjoner knyttet til seg, omtrent som modeller i andre MVC-rammer. Den magiske delen av Backbone-modeller er at vi kan binde hendelser til attributter, slik at når dette attributtet endres, kan vi oppdatere synspunktene våre for å gjenspeile det. Men vi kommer litt foran oss selv.

Når vi henter bildene fra Flickr, skal vi få nok informasjon til å lage nettadresser for alle størrelser. Imidlertid er den samlingen overlatt til oss, så vi implementerte .image_url () -funksjonen som tar en størrelsesparameter og returnerer en offentlig lenke. Fordi dette er en ryggradsmodell, kan vi bruke this.get () for å få tilgang til attributter på modellen. Så med denne modellen kan vi gjøre følgende andre steder i koden for å få URL til et Flickr-bilde.

flickrImage.image_url (’stor’)

Ganske kortfattet, ikke sant? Siden denne modellen er spesifikk for applikasjonen vår, vil vi legge til noen innpakningsfunksjoner for størrelsen på størrelse og tommel.

En samling bilder

FlickrBomb håndterer samlinger av bilder, ikke enkeltbilder, og Backbone har en praktisk måte å modellere dette på. Den passende navnet Collection er det vi skal bruke til å gruppere Flickr-bilder for en enkelt plassholder.

Det er et par ting å merke seg her. Først av, den modell attributt forteller samlingene hvilken type modell den samler inn. Vi har også noen attributter som vi initialiserte for bruk senere: nøkkelen er vår Flickr API-nøkkel, du vil erstatte flickrbombAPIkey med strengen til din egen Flickr API-nøkkel. Å få en Flickr API-nøkkel er gratis og enkelt, bare følg denne lenken: www.flickr.com/services/api/misc.api_keys.html. Sideattributtet er den gjeldende siden med Flickr-bilder vi er på.

Den store metoden her er .fetch (), som trekker bort detaljene for å hente bilder fra Flickr API. For å unngå problemer med forespørsler på tvers av domener, bruker vi JSONP, som både Flickr API og jQuery støtter. De andre parametrene vi overfører til API-en, bør være selvforklarende. Av spesiell interesse er Backbone-funksjonene som kalles her. I den vellykkede tilbakeringingen vi bruker .add (), en funksjon som tar en rekke modellattributter, oppretter modellforekomster fra disse attributtene, og legger dem deretter til samlingen.

Funksjonene .nextPage () og .prevPage () endrer først siden vi vil vise,
bruk samlefunksjonen .remove () for å fjerne alle eksisterende modeller fra
samling, og ring deretter for å hente bilder for den nåværende siden (som vi bare
endret).

The FlickrBombImage

Når vi jobber oss opp igjen, trenger vi en modell til for å representere plassholderbildet, som vil bestå av en samling FlickrImages og den nåværende FlickrImage som er valgt. Vi vil kalle denne modellen FlickrBombImage.

Siden denne modellen er ansvarlig for å holde oversikt over det valgte bildet mellom sidelasting, må den vite hvilken lokal butikk som skal brukes.Den første linjen vil sikre at det er støtte for lokal lagring, og deretter opprette butikken vi vil bruke for å vedvare det valgte bildet.

Backbone lar oss definere en .initialize () -funksjon som blir kalt når en forekomst av modellen opprettes. Vi bruker denne funksjonen i FlickrBombImage for å lage en ny forekomst av FlickrImages-samlingen, passere nøkkelordene som skal brukes til dette bildet, og deretter hente bildene fra Flickr.

.LoadFirstImage () -funksjonen er sendt som en tilbakeringing for å kjøre når bildene er lastet inn fra Flickr. Som du sikkert kan gjette, setter denne funksjonen det nåværende bildet til å være det første i samlingen fra Flickr. Det gjør ikke dette hvis det nåværende bildet allerede er satt.

Vi skal også bruke Backbones attributt-tilbakeringinger for å utløse .changeSrc () -funksjonen når src-attributtet til denne modellen endres. Alt dette tilbakeringingen gjør er å ringe .save (), en Backbone-modellfunksjon som fortsetter modellens attributter til det butikklaget som er implementert (i vårt tilfelle localstore). Denne måten, når det valgte bildet endres, vedvares det umiddelbart.

Utsiktslaget

Nå som vi har skrevet all backend (vel, frontend backend) -koden, kan vi sette sammen Views. Visninger i ryggraden er litt forskjellige fra andre tradisjonelle MVC-rammer. Mens en visning vanligvis bare handler om presentasjon, er en Backbone View også ansvarlig for atferd. Det betyr at View ikke bare definerer hvordan noe ser ut, men også hva det skal gjøre når det samhandles med.

En visning er ofte (men ikke alltid) knyttet til noen data, og går gjennom tre faser for å generere presentasjonsmarkering fra disse dataene:

1. Vis-objektet initialiseres, og et tomt element opprettes.
2. Render-funksjonen kalles, og genererer markeringen for visningen ved å sette den inn i elementet som ble opprettet i forrige trinn.
3. Elementet er festet til DOM.

Dette kan virke som mye arbeid for å generere en viss markering, og vi er ikke engang til atferdsdelen av View ennå, men det er viktig, og her er hvorfor. Hver gang du endrer elementer som er i DOM, utløser du noe som kalles et nettleserflow. Et omløp er nettleseren som beregner hvordan hver ting på siden er plassert. Nettleseroverflytninger kan være dårlige for ytelsen hvis de blir kalt i en dra eller endre størrelse på hendelsen, som utløses med et veldig kort intervall, men verre, de ser slurvete ut. Med komplisert sidemanipulering kan du faktisk se at elementer legges til på siden, og hvordan elementene plasseres på nytt. Etter Backbones mønster for initialisering, gjengivelse og vedlegg garanterer du et enkelt tilbakeslag, og endringene på siden vil være perceptivt øyeblikkelige, uavhengig av kompleksiteten i elementmanipulering.

FlickrBombImageView

Funksjonene til denne visningen er utelatt for kortfattethet, kildekoden i sin helhet er tilgjengelig på GitHub: github.com/zurb/flickrbomb

Øverst i visningen har vi et par spesifikke attributter for ryggraden. tagName og className brukes til å definere taggen og classen som skal brukes på elementet til denne visningen. Husk at trinn ett i Vis opprettelse er å lage et objekt, og siden den opprettelsen håndteres av Backbone, må vi spesifisere elementet og klassen. Merk at Backbone har fornuftige standardverdier; hvis vi utelater disse attributtene, brukes en div som standard, og ingen klasse blir brukt med mindre du spesifiserer en.

Malattributtet er en konvensjon, men ikke påkrevd. Vi bruker den her for å spesifisere JavaScript-malfunksjonen vi vil bruke til å generere vår markering for denne visningen. Vi bruker _.template () -funksjonen som er inkludert i Underscore.js, men du kan bruke hvilken malmotor du foretrekker, vi vil ikke dømme deg.

I .initialize () -funksjonen vår trekker vi ut nøkkelordstrengen fra bildekoden, og lager deretter en FlickrBombImage-modell ved hjelp av disse nøkkelordene. Vi binder også .addImage () -funksjonen som skal kjøres når en FlickrImage legges til i FlickrImages-samlingen. Denne funksjonen vil legge til den nylig tilførte FlickrImage i vår billedvelgerflyout. Den siste og viktigste linjen er å binde .updateSrc () -funksjonen til å utløse når den valgte FlickrImage endres. Når det nåværende bildet endres i modellen, vil denne funksjonen kjøre, oppdatere src-attributtet til bildeelementet, og CSS endre størrelse og beskjære bildet slik at det passer innenfor bildedimensjonene som er angitt av brukeren.

hendelser: {"click .setupIcon": "clickSetup", "click .flickrbombFlyout a.photo": "selectImage", "click .flickrbombFlyout a.next": "nextFlickrPhotos", "click .flickrbombFlyout a.prev": "prevFlickrPhotos "}

Etter .initialize () har vi atferdsdelen av visningen. Backbone gir en praktisk måte å binde hendelser ved hjelp av et hendelsesobjekt. Hendelsesobjektet bruker jQuery .delegate () -metoden for å gjøre den faktiske bindingen til View-elementet, slik at uansett hvilken manipulasjon du gjør med elementet i visningen, vil alle dine bundet hendelser fremdeles fungere. Det fungerer akkurat som jQuery .live (), bortsett fra at i stedet for å binde hendelser til hele dokumentet, kan du binde dem innenfor rammen av ethvert element. Nøkkelen til hver oppføring i hendelsesobjektet består av hendelsen og velgeren, verdien indikerer den funksjonen som skal være bundet til den hendelsen. Merk at .delegate () ikke fungerer med noen hendelser som sende inn, se dokumentasjonen jQuery .live () for en komplett liste over støttede hendelser.

gjengi: funksjon () {$ (this.el) .html (this.template ()); this.image.fetch (); this.resize (); returner dette;}

Til slutt har vi .render () -funksjonen som er ansvarlig for å opprette markeringen vår og utføre tilleggsarbeid som ikke kan utføres før View-markeringen er lagt til View-elementet. Når vi har gjengitt malen, må vi ringe .fetch () på FlickrBombImage. .fetch () er en ryggradsfunksjon som får den siste kopien av modellen fra utholdenhetslaget. Hvis vi hadde lagret denne modellen før, ville .fetch () hente dataene nå. Etter at bildet er hentet, må vi ringe størrelse for å plassere det riktig.

Hjemmestrekningen

Med alle brikkene på plass er alt vi trenger å gjøre nå å finne plassholderbildene på siden og erstatte dem med de gjengitte FlickrBombImage-visningene.

$ ("img [src ^ = 'flickr: //']") .each (function () {var img = $ (this), flickrBombImageView = new FlickrBombImageView ({img: img}); img.replaceWith (flickrBombImageView. gjengi (). el);});

Dette lille utdraget må kjøres nederst på siden, eller i en tilbakekalling for dokument, for å sikre at den finner plassholderbildene den skal erstatte. Vi bruker konvensjonen om å spesifisere flickr: // [KEYWORD] i src-attributtet til en bildekode for å indikere at den skal fylles med bilder fra Flickr. Vi finner bildeelementer med et matchende src-attributt, lager en ny FlickrBombImageView, og erstatter deretter bildet med vårt. Vi tar en kopi av det originale bildet og sender det til FlickrBombView, slik at vi kan trekke noen ekstra konfigurasjonsalternativer som kan ha blitt spesifisert på elementet.

Sluttresultatet av alt det harde arbeidet er en veldig enkel API for folk som bruker biblioteket. De kan ganske enkelt definere bildekoder ved å bruke flickr: // -konvensjonen, slippe FlickrBomb-koden nederst på siden og bam, de har plassholderbilder fra Flickr.

Fungerer bra med store ol nettapper også

Vi har en stor ol-webapp kalt Notable, som ble skrevet uten bekymring for å generere innhold på klientsiden. Da vi ønsket å lage deler av app-turboen ved å generere innholdsklientsiden, valgte vi Backbone. Årsakene var de samme: vi ønsket et lett rammeverk for å holde koden organisert, men ikke tvinge oss til å revurdere hele applikasjonen.

Vi lanserte endringene tidligere i år med stor suksess, og har sunget Backbones ros siden.

Tilleggsressurser

Det er mye mer å Backbone enn det jeg dekket i denne artikkelen, C (kontroller) -delen av MVC (modellvisningskontroll) for å begynne med, som faktisk er en R (router) i den siste versjonen. Og det hele er dekket i Backbone-dokumentasjonen, en lett lørdag morgen leste:
documentcloud.github.com/backbone/

Hvis mer tradisjonelle opplæringsprogrammer er noe for deg, så sjekk ut den veldig godt dokumenterte koden til dette todo-programmet skrevet i Backbone:
documentcloud.github.com/backbone/docs/todos.html

Forrige Artikkel