Share
Ci sono molte librerie JavaScript disponibili e la maggior parte sono davvero brave a fornire le tradizionali interazioni DOM-centric che i tuoi siti web tipici hanno bisogno. Ma quando è il momento di creare una base di codice gestibile per un'applicazione a singola pagina, è qui che entra un'intera suite di nuovi framework per appianare le cose.
Il vecchio detto è vero: "Usa lo strumento migliore per l'attività".
Non è che le librerie tradizionali come jQuery non possano aiutarti a costruire esperienze simili a quelle del desktop, non è solo il caso d'uso per questo e mancano cose come l'associazione dati, il routing degli eventi e la gestione dello stato. Certo, puoi probabilmente accumulare un sacco di plugin per ottenere alcune di queste funzionalità, ma partire da un framework che è stato appositamente costruito da zero per affrontare questi problemi specifici, a mio parere, ha più senso. Il vecchio detto è vero: "Usa lo strumento migliore per l'attività".
Recentemente ho fatto un'intervista con il team Ember.js; è stato motivato dal mio desiderio di conoscere quello che sono venuto a chiamare "il nuovo hotness": Ember.js.
Ember si adatta al progetto per quello che ho descritto sopra, e lo fa in un modo che ricorda molto di quanto jQuery consenta agli sviluppatori di essere subito operativi. Il team ha intenzionalmente preso provvedimenti per astrarre molte delle complessità inerenti alla progettazione e alla realizzazione di applicazioni basate su Model / View / Controller utilizzando anni di esperienza e conoscenze acquisite dalla creazione di app su larga scala.
Quello che mi piacerebbe fare è aiutarti a metterti al passo con Ember.js, attraverso una serie di articoli in più parti che ti introdurrà gradualmente ai concetti del framework. Inizieremo con la solita introduzione (che sembra essere questo post), per poi passare gradualmente alla creazione di un'applicazione completa. La parte migliore è che questo mi aiuterà anche a rafforzare i concetti che ho già imparato, e forse raccoglierò alcune nuove tecniche lungo la strada! Farò del mio meglio per fare in modo che il team di Ember.js riesamini questo materiale per precisione e forse contribuisca anche con qualche pepita.
Prima di continuare, a testa alta: Ember.js fa un sacco di magia per te. Ci sono volte in cui guarderai il codice e dirai "Eh? Come lo hai fatto?" Sono stato lì e farò del mio meglio per distillare le cose, ma non ho intenzione di immergermi nelle viscere del codice quadro di Ember. Piuttosto, discuterò di come puoi sfruttare i suoi strumenti e le API per creare la tua app.
Quindi diamo il calcio d'inizio.
Ember.js non è un framework per la creazione di siti Web tradizionali.
La prima cosa da tenere a mente è che Ember.js non è un framework per la creazione di siti Web tradizionali. Librerie come jQuery e MooTools sono perfette per questo. Se stai prendendo in considerazione Ember.js, supponiamo che tu stia cercando di costruire esperienze simili a desktop, in particolare quelle scalabili. In effetti, lo slogan per il framework è "un framework per lo sviluppo di applicazioni web ambiziose" che ti dice che chiaramente non è la libreria JavaScript di tuo padre.
Ho già detto che Ember sfrutta il pattern MVC per promuovere la corretta gestione e organizzazione del codice. Se non hai mai fatto uno sviluppo basato su MVC, dovresti assolutamente leggerlo. Nettuts + ha un grande articolo sull'argomento qui. Per quelli di voi che conoscono i concetti, dovreste sentirvi a casa. L'unica cosa che ho sentito in modo coerente è che rendere il passaggio da Backbone a Ember.js è in realtà facile perché Ember fa molto per te, pur mantenendo i modelli di organizzazione del codice a cui quegli sviluppatori sono abituati.
Ember si basa anche su modelli lato client ... a LOT. Utilizza la libreria di modelli Handlebars che fornisce espressioni che consentono di creare modelli dinamici basati su HTML. Uno sviluppatore Ember può associare dati a queste espressioni incorporabili e modificare dinamicamente la visualizzazione della propria app al volo. Ad esempio, posso creare un modello che può ricevere una schiera di persone e visualizzarle in un elenco non ordinato:
Si noti l'espressione "#each" che funziona come una direttiva loop, che enumera su ogni elemento della matrice "persone" e sostituisce l'espressione "nome" con un valore effettivo. È importante notare che le parentesi doppie sono token utilizzati da Handlebars per identificare le espressioni. Questo è un piccolo esempio e ci tufferemo più in dettaglio in seguito.
Handlebars è un motore di template sul lato client incredibilmente potente e io raccomanderei di rivedere non solo le guide di Ember, ma il sito stesso di Handlebars stesso per avere una conoscenza completa delle opzioni disponibili. Lo userai un bel po '.
Ember.js si basa su librerie aggiuntive, quindi avrai bisogno di prendere una copia di jQuery e Handlebars. Ma, aspetta, non ho detto che jQuery ed Ember suonano in spazi diversi? Beh, sì, l'ho fatto, ma ecco la cosa: il team Ember non si tratta di reinventare la ruota. Hanno scelto jQuery per fare ciò che sa fare meglio: lavorare con il DOM. E questa è una buona cosa, dal momento che jQuery è davvero bravo in questo. È anche il motivo per cui sono andati con Handlebars, che è un'eccellente libreria di modelli che è stata scritta da Yehuda Katz, che è un membro del team di base di Ember.
Il modo più semplice per ottenere i file necessari è andare al repository Github Ember.js e tirare giù lo Starter Kit. È uno standard per iniziare. Al momento di questa scrittura, contiene:
C'è anche un modello html di base che è codificato per includere tutte le librerie associate (jQuery, Ember, ecc.) E un esempio di un modello di Handlebars e "app.js", che include il codice per avviare un'app di base di Ember.
Tieni presente che app.js non fa parte del framework. È un semplice file JavaScript; puoi chiamarlo come vuoi E, mentre lo useremo per gli scopi di questa serie di tutorial, probabilmente finirai per suddividere il tuo JavaScript in più file proprio come faresti per qualsiasi altro sito o app. Inoltre, Ember non si aspetta una struttura di directory specifica per i file framework.
Quando si guarda il codice del kit di base, potrebbe sembrare il codice tipico del sito web. Per certi versi, hai ragione! Una volta che iniziamo ad organizzare le cose, vedrai come la costruzione di un'app Ember è diversa.
Prima di iniziare a hackerare il codice, è importante capire come funziona Ember.js e se si utilizzano le parti mobili che compongono un'app Ember. Diamo un'occhiata a quelle parti e come si relazionano tra loro.
I modelli sono una parte fondamentale della definizione dell'interfaccia utente. Come accennato in precedenza, Handlebars è la libreria lato client utilizzata in Ember e le espressioni fornite dalla libreria sono ampiamente utilizzate durante la creazione dell'interfaccia utente per la propria applicazione. Ecco un semplice esempio:
Nota che le espressioni sono mescolate nel tuo markup HTML e, tramite Ember, cambieranno in modo dinamico il contenuto visualizzato nella pagina. In questo caso, i segnaposto firstName e lastName verranno sostituiti dai dati recuperati dall'app.
Manubri offre molta potenza, tramite un'API flessibile. Sarà importante per te capire cosa offre.
Il router di un'applicazione aiuta a gestire lo stato dell'applicazione.
Il router di un'applicazione aiuta a gestire lo stato dell'applicazione e le risorse necessarie mentre un utente naviga l'app. Ciò può includere attività quali la richiesta di dati da un modello, il collegamento di controller a viste o la visualizzazione di modelli.
Puoi farlo creando un percorso per posizioni specifiche all'interno della tua applicazione. Le rotte specificano parti dell'applicazione e gli URL ad esse associati. L'URL è l'identificatore chiave utilizzato da Ember per capire quale stato dell'applicazione deve essere presentato all'utente.
Accentsconagua
App.Router.map (function () this.route ('about'); // Ci porta a "/ about"); I comportamenti di una rotta (ad es .: richiesta di dati da un modello) sono gestiti tramite istanze dell'oggetto di rotta Ember e vengono attivati quando un utente naviga verso un URL specifico. Un esempio potrebbe richiedere dati da un modello, come questo:
App.EmployeesRoute = Ember.Route.extend (model: function () return App.Employee.find (););
In questo caso, quando un utente accede alla sezione "/ dipendenti" dell'applicazione, il percorso invia una richiesta al modello per un elenco di tutti i dipendenti.
Una rappresentazione dell'oggetto dei dati.
I modelli sono una rappresentazione a oggetti dei dati che la tua applicazione utilizzerà. Potrebbe essere un semplice array o dati recuperati dinamicamente da un'API JSON RESTful, tramite una richiesta Ajax. La libreria Ember Data offre l'API per caricare, mappare e aggiornare i dati sui modelli all'interno dell'applicazione.
I controller vengono generalmente utilizzati per archiviare e rappresentare i dati e gli attributi del modello. Si comportano come un proxy, dandoti accesso agli attributi del modello e consentendo ai modelli di accedervi per rendere il display dinamicamente. Questo è il motivo per cui un modello sarà sempre connesso a un controller.
La cosa principale da ricordare è che, mentre un modello recupera i dati, un controller è ciò che utilizzerai per esporre a livello di programmazione quei dati a diverse parti della tua applicazione. Sebbene possa sembrare che i modelli e i controller siano strettamente accoppiati, infatti, i modelli stessi non hanno alcuna conoscenza dei controller che li useranno più tardi.
È inoltre possibile memorizzare altre proprietà dell'applicazione che devono essere persistenti ma non devono essere salvate su un server.
Le viste in Ember.js sono pensate per gestire eventi attorno all'interazione dell'utente e tradurli in eventi che hanno un significato all'interno della tua applicazione. Pertanto, se un utente fa clic su un pulsante per eliminare un dipendente, la vista è responsabile dell'interpretazione di quell'evento di clic del browser nativo e dell'elaborazione in modo appropriato nel contesto dello stato corrente dell'applicazione.
Uno dei modi in cui Ember.js aiuta a ridurre al minimo la quantità di codice necessaria e gestire le cose dietro le quinte è attraverso convenzioni di denominazione. Il modo in cui definite e denominate i percorsi (e le risorse) influisce sulla denominazione di controller, modelli, viste e modelli. Ad esempio, se creo un percorso, chiamato "dipendenti":
App.Router.map (function () this.resource ('employees');); Vorrei quindi nominare i miei componenti, in questo modo:
L'uso di questa convenzione di denominazione ha un duplice scopo. Primo, ti dà una relazione semantica tra componenti simili. In secondo luogo, Ember può creare automaticamente gli oggetti necessari che potrebbero non esistere (ad es. Un oggetto di percorso o un controller) e collegarli per l'uso nell'applicazione. Questa è la "magia" di cui ho parlato prima. In effetti, questo è specificamente ciò che Ember fa a livello di applicazione globale, quando si istanzia l'oggetto Application:
var app = Ember.Application.create ();
Quella singola riga crea i riferimenti predefiniti al router, al controller, alla vista e al modello dell'applicazione.
Tornando al percorso "dipendenti" che ho creato sopra, ciò che accadrà è che, quando un utente naviga verso "/ dipendenti" nella tua applicazione, Ember cercherà i seguenti oggetti:
Se non li trova, creerà un'istanza di ciascuno ma semplicemente non renderà nulla, dal momento che non hai specificato un modello per ricavare dati da o un modello con cui visualizzare i dati. Questo è il motivo per cui la convenzione di denominazione è così importante. Consente a Ember di sapere come gestire le attività associate a un percorso specifico, senza dover collegare le cose manualmente.
Si noti che, nel primo esempio, ho utilizzato il nome singolare "Dipendente" per definire il modello. Questo è apposta. La natura stessa del nome "Dipendenti" impone che io possa lavorare con 0 a molti dipendenti, quindi è importante costruire un modello che possa fornire la flessibilità per restituire un dipendente o tutti i dipendenti. La singolare convenzione di denominazione di questo modello non è un requisito di Ember, in quanto i modelli stessi non hanno alcuna conoscenza dei controller che li useranno in seguito. Quindi hai la flessibilità nel nominarli, ma per coerenza, attenersi a questa convenzione renderà la gestione del codice sostanzialmente più semplice.
Inoltre, ho scelto di usare il risorsa() metodo per definire il mio percorso, perché in questo scenario, molto probabilmente avrei percorsi nidificati per gestire le pagine di dettaglio per informazioni specifiche sui dipendenti. Parleremo di nidificazione più avanti nella serie.
Il punto chiave è che utilizzando uno schema di denominazione coerente, Ember può facilmente gestire gli hook che collegano questi componenti insieme senza la necessità di definire esplicitamente le relazioni tramite una tonnellata di codice.
I dettagli completi delle convenzioni di denominazione di Ember sono forniti sul sito del progetto ed è a devi leggere.
Nella parte successiva della serie, ci tufferemo nel codice per creare le basi della nostra applicazione.
Abbiamo esaminato i concetti chiave di Ember e discusso i principali aspetti di alto livello del framework. Nella parte successiva della serie, ci tufferemo nel codice per creare le basi della nostra applicazione. Nel frattempo, desidero nuovamente consigliare di iniziare a consultare la documentazione di Handlebars per avere un'idea della sintassi delle espressioni. Inoltre, se stai davvero calpestando il bit per entrare in Ember, resta sintonizzato su Tuts + Premium, che offrirà presto un corso completo che ti guiderà attraverso la creazione di un'applicazione basata su Ember!
Come ho notato all'inizio di questo articolo, Ember.js Core Team guida Yehuda Katz e Tom Dale esaminando questo per la precisione, e ha dato il pollice in su. La squadra di Ember ha approvato! Ci vediamo tra un po '!
