Quali sono i punti di forza e di debolezza del mondo reale dei numerosi framework basati su backbone.js? [chiuso]


186

Spero che qualcuno possa condividere la propria esperienza con alcune delle più recenti varianti emergenti di backbone.js disponibili. Ho una buona esperienza con backbone / carattere di sottolineatura / richiesta in diversi progetti e mi piacerebbe fare il passo successivo verso soluzioni più avanzate per la struttura di applicazioni complesse.

So che sono disponibili i seguenti framework:

E probabilmente ne ho persi alcuni.

Ecco una breve introduzione sulle differenze qui:

ma è molto generale. Mi chiedevo se qualcuno potesse condividere la propria esperienza con applicazioni della vita reale usando questi framework.

Qual è il vantaggio di scegliere l'uno rispetto all'altro? Quando la marionetta sarà una soluzione migliore rispetto a Chaplin, o perché le vetebre sono migliori per alcune applicazioni, ad esempio.

Certo, la risposta ovvia sarà " usare ciò che è meglio per le tue esigenze ", ma mi manca l'esperienza con questi framework per conoscerne la forza / lo scopo / i vantaggi o gli scenari preferiti.

Grazie!

Modifica 1: trovato questo post: Backbone.Marionette vs Backbone-Boilerplate

Modifica 2: Risposta di Mathias schafer (Chaplin) via mail:

In breve, l'attuale struttura è vicina alla versione 1.0 poiché è già utilizzata in produzione. Non stiamo pianificando di aggiungere nuove grandi funzionalità o interrompere le modifiche API fino alla 1.0.

Marionette è sicuramente la biblioteca più completa e stabile in circolazione. Risolve diversi aspetti dello sviluppo di app JS con Backbone. Ad esempio, ha un forte livello di visualizzazione che Backbone stesso lascia completamente vuoto. Naturalmente, scoprirai che alcuni aspetti non soddisfano le tue esigenze e potresti sentire la necessità di creare una struttura attorno alla marionetta.

Al contrario, Chaplin si concentra su un aspetto piuttosto piccolo, ma molto importante delle app Backbone, vale a dire la struttura generale dell'app e il ciclo di vita del modulo. A questo proposito Chaplin è molto motivato ed è più simile a un framework che a una libreria (come in "il tuo codice chiama una libreria, un framework chiama il tuo codice"). Chaplin fornisce alcune classi centrali che si trovano sopra i singoli moduli dell'applicazione e controllano lo stato generale dell'app. Questo dà alla tua app una struttura convenzionale come fa Ruby on Rails.

In Chaplin, dichiari alcuni percorsi che mappano ai controller e Chaplin avvia il controller una volta che il percorso corrisponde. Si occupa anche dello smaltimento dei vecchi controller e della visualizzazione e occultamento delle viste principali, che dovrebbe essere creato da un controller. Questa è l'idea di base, ma Chaplin si prende cura dei dettagli brutti per farlo funzionare senza intoppi.

Esistono due principi che accompagnano questa struttura: - Modularizzazione, disaccoppiamento e sandboxing - Comunicazione tra moduli mediante Pubblica / Abbonati e Mediatore / i

Naturalmente questi schemi non sono nuovi nel mondo dello sviluppo del software e Chaplin non è l'unica libreria che li applica alle app Backbone.js.

Chaplin fornisce anche miglioramenti per il livello View, ad esempio un CollectionView altamente sofisticato, ma in totale non tanto quanto Marionette con le sue regioni e layout. Ma è relativamente facile scrivere tali meta-classi usando i mezzi forniti da Chaplin Views.


12
+1 La tua domanda è arrivata al punto. Nel corso dell'ultimo anno o due una sorta di campagna pubblicitaria ha gonfiato il paesaggio con innumerevoli progetti ispirati all'architettura che sono davvero difficili da differenziare - ognuno dei quali implementa un approccio leggermente personale e più che spesso gonfio nel fare le cose. Nota che questo è un commento :)
kontur

Risposte:


132

La maggior parte (tutti?) Dei framework che stai esaminando risolvono gli stessi problemi, ma lo fanno in modi leggermente diversi con obiettivi leggermente diversi.

Penso che sia giusto dire che tutti questi progetti risolverebbero i problemi in queste categorie:

  • Fornire una serie ragionevole di valori predefiniti
  • Ridurre il codice del boilerplate
  • Fornire la struttura dell'applicazione sopra i blocchi predefiniti di BackboneJS
  • Estrai i pattern che gli autori usano nelle loro app

Marionette, che costruisco dal dicembre 2011, ha in mente anche alcuni obiettivi e ideali molto distinti:

  • Architettura dell'applicazione composita
  • Influenza del modello di messaggistica aziendale
  • Opzioni di modularizzazione
  • Uso incrementale (nessun requisito tutto o niente)
  • Nessun blocco del server
  • Semplifica la modifica di tali valori predefiniti
  • Codice come configurazione / sopra configurazione

Non sto dicendo che nessuno degli altri framework abbia gli stessi obiettivi. Ma penso che l'unicità di Marionette derivi dalla combinazione di questi obiettivi.

Architettura dell'applicazione composita

Ho trascorso più di 5 anni a lavorare in sistemi software distribuiti a client spesso usando WinForms e C #. Ho creato app per desktop, laptop (smart-client), dispositivi mobili e applicazioni Web, condividendo tutte un set funzionale di base e lavorando più volte con lo stesso back-end del server. In questo periodo ho appreso il valore della modularizzazione e ho intrapreso molto rapidamente un percorso di progettazione di applicazioni composite.

L'idea di base è quella di "comporre" l'esperienza di runtime dell'applicazione e di elaborare molti singoli pezzi più piccoli che non si conoscono necessariamente. Si registrano con il sistema complessivo di applicazione composita e quindi comunicano attraverso vari mezzi di messaggi e chiamate disaccoppiati.

Ho scritto un po 'di questo sul mio blog, introducendo Marionette come architettura composita per l'applicazione Backbone:

Code / pattern dei messaggi

Gli stessi sistemi distribuiti su larga scala hanno inoltre sfruttato l'accodamento dei messaggi, i modelli di integrazione aziendale (modelli di messaggistica) e i bus di servizio per gestire i messaggi. Questo, più di ogni altra cosa, ha avuto un'enorme influenza sul mio approccio allo sviluppo del software disaccoppiato. Ho iniziato a vedere le applicazioni WinForms single-process in memoria da questa prospettiva, e presto il mio lato server e lo sviluppo di applicazioni web ne hanno influenzato.

Questo si è tradotto direttamente nel modo in cui guardo il design dell'applicazione Backbone. Fornisco un aggregatore di eventi in Marionette, sia per l'oggetto Application di alto livello, sia per ciascun modulo creato all'interno dell'applicazione.

Penso ai messaggi che posso inviare tra i miei moduli: messaggi di comando, messaggi di eventi e altro ancora. Penso anche alla comunicazione lato server come messaggi con questi stessi schemi. Alcuni dei motivi si sono già fatti strada verso Marionette, ma alcuni non l'hanno ancora fatto.

La modularizzazione

La modularizzazione del codice è estremamente importante. La creazione di pacchetti piccoli e ben incapsulati con un focus singolare con punti di entrata e uscita ben definiti è un must per qualsiasi sistema di dimensioni e complessità significative.

Marionette fornisce la modularizzazione direttamente attraverso le sue moduledefinizioni. Ma riconosco anche che alcune persone come RequireJS e vogliono usarlo. Quindi fornisco sia una build standard che una build compatibile con RequireJS.


MyApp = new Backbone.Marionette.Application();

MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){

  // your module code goes here

});

(Non ci sono ancora post sul blog disponibili per questo)

Uso incrementale

Questa è una delle filosofie fondamentali in cui mi concentro su ogni parte della marionetta che posso: nessun requisito "tutto o niente" per l'uso della marionetta.

Backbone stesso adotta un approccio molto incrementale e modulare con tutti i suoi oggetti di blocco. Sei libero di scegliere quali vuoi usare, quando. Credo fermamente in questo principio e mi sforzo di assicurarmi che la Marionetta funzioni allo stesso modo.

A tal fine, la maggior parte dei pezzi che ho incorporato in Marionette sono costruiti per essere isolati, per lavorare con i pezzi principali di Backbone e per lavorare insieme ancora meglio.

Ad esempio, quasi tutte le applicazioni Backbone devono mostrare dinamicamente una vista Backbone in un determinato punto dello schermo. Le app devono anche gestire la chiusura di vecchie viste e la pulizia della memoria quando ne viene creata una nuova. È qui che Regionentra in gioco Marionette . Un'area gestisce il codice del boilerplate per visualizzare una vista, chiamare il rendering su di essa e inserire il risultato nel DOM per te. Quindi chiuderà quella vista e la pulirà per te, a condizione che la tua vista abbia un metodo di "chiusura" su di essa.


MyApp.addRegions({
  someRegion: "#some-div"
});

MyApp.someRegion.show(new MyView());

Ma non è necessario utilizzare le visualizzazioni di Marionette per utilizzare una regione. L'unico requisito è che si stia estendendo da Backbone.View ad un certo punto nella catena di prototipi dell'oggetto. Se scegli di fornire un closemetodo, un onShowmetodo o altri, la Regione delle Marionette lo chiamerà per te al momento giusto.

Nessun blocco del server

Realizzo app Backbone / Marionette su un'ampia gamma di tecnologie server:

  • ASP.NET MVC
  • Ruby on Rails
  • Rubino / Sinatra
  • NodeJS / ExpressJS
  • PHP / Slim
  • Giava
  • Erlang
  • ... e altro ancora

JavaScript è JavaScript, quando si tratta di funzionare in un browser. Anche il lato server JavaScript è fantastico, ma non ha alcun effetto o influenza su come scrivo JavaScript basato sul mio browser.

A causa della diversità dei progetti che ho realizzato e delle tecnologie di back-end utilizzate dai miei clienti, non posso e non voglio bloccare Marionette su un singolo stack tecnologico lato server per nessun motivo. Non fornirò un progetto di boilerplate. Non fornirò una gemma rubino o un pacchetto npm. Voglio che le persone capiscano che Marionette non richiede un server back-end specifico. È JavaScript basato su browser e il back-end non ha importanza.

Ovviamente, appoggio pienamente altre persone fornendo pacchetti per la loro lingua e struttura. Elenco questi pacchetti nel Wiki e spero che le persone continuino a creare più pacchetti quando ne vedono la necessità. Ma questo è il supporto della comunità, non il supporto diretto di Marionette.

Modifica facilmente i valori predefiniti

Nel mio tentativo di ridurre il codice del boilerplate e fornire impostazioni predefinite ragionevoli (che è un'idea che ho "preso in prestito" direttamente dal LayoutManager di Tim Branyen), riconosco la necessità che altri sviluppatori utilizzino implementazioni leggermente diverse rispetto a me.

Fornisco il rendering basato su <script>tag incorporati per i modelli, usando il template Underscore.js per impostazione predefinita. Ma puoi sostituirlo cambiando gli oggetti Renderere / o TempalteCachein Marionette. Questi due oggetti forniscono il nucleo delle funzionalità di rendering e ci sono pagine wiki che mostrano come modificarlo per motori di template specifici e modi diversi di caricare i template.

Con la v0.9 di Marionette, diventa ancora più facile. Ad esempio, se si desidera sostituire l'uso di blocchi di script modello inline con modelli precompilati, è necessario sostituire un solo metodo sul Renderer:


Backbone.Marionette.Renderer.render = function(template, data){
  return template(data);
};

e ora l'intera applicazione utilizzerà modelli precompilati da allegare templateall'attributo della vista .

Fornisco anche un componente aggiuntivo Marionette.Async con v0.9 che consente di supportare il rendering asincrono delle viste. Mi sforzo continuamente di semplificare il più possibile la sostituzione dei comportamenti predefiniti in Marionette.

Codice come configurazione

Sono un fan della "convenzione sulla configurazione" in determinati contesti. È un modo potente per fare le cose, e Marionette ne fornisce un po ', anche se non troppo, onestamente. Molti altri framework, in particolare LayoutManager, forniscono più convenzioni sulla configurazione rispetto a Marionette.

Questo viene fatto con uno scopo e un intento.

Ho creato abbastanza plugin, framework, componenti aggiuntivi e applicazioni JavaScript per conoscere il dolore di provare a far funzionare le convenzioni in modo rapido e significativo. Può essere fatto con velocità, ma di solito a costo di poterlo cambiare.

A tal fine, prendo un approccio "code as configuration" a Marionette. Non fornisco molte API di "configurazione" in cui è possibile fornire un oggetto letterale con valori statici che cambiano una serie di comportamenti. Invece, documento i metodi che ogni oggetto ha - sia attraverso il codice sorgente annotato che attraverso la documentazione API effettiva - con l'intento di dirti come cambiare la marionetta in modo che funzioni nel modo desiderato.

Fornendo un'API pulita e chiara per gli oggetti Marionette, creo una situazione in cui sostituire il comportamento di un oggetto specifico o Marionette nel suo insieme è relativamente semplice e molto flessibile. Sacrifico le "semplici" API di configurazione per la flessibilità di fornire il proprio codice per far funzionare le cose nel modo desiderato.

Non troverai un'API "configura" o "opzioni" in Marionette. Ma troverai un gran numero di metodi che hanno ciascuno uno scopo molto specifico, con firme pulite, che rendono facile cambiare il modo in cui funziona la marionetta.


16
Perché questa è la risposta più votata? Non risponde alla domanda - è fondamentalmente una storia / pubblicità per Marionette ...
Jess Telford

@JessTelford potresti voler rileggere la domanda, è una risposta abbastanza buona.
mor

@mor la domanda è What is the benefit of choosing one over the other?- questa è la risposta Marionette [...] has a few very distinct goals and ideals in mind, che non si confronta una volta con un altro framework. Se la domanda era, per favore, spiega cosa può fare ciascuno di questi quadri , quindi sicuramente questa è un'ottima risposta. Ma non lo era. E non lo è.
Jess Telford,

@JessTelford La domanda richiede chiaramente risposte multiple. Questo afferma i punti di forza e i problemi che Marionette affronta. Dopo aver letto la domanda, ho trovato questa risposta davvero utile. Non è necessariamente il migliore secondo me, ma è comunque una buona risposta. Oh, e la domanda è: What are the strengths and weaknesses of....
mor

@mor Non fraintendetemi - questa è una descrizione molto completa e chiara di Marionette. Non sento che risponda alla domanda. Ad ogni modo, i voti positivi sono per questo una buona risposta.
Jess Telford,

25

Attualmente sto usando backbone con il modulo di gestione layout e manubri come motore di template e ho trovato davvero facile impostare una piccola applicazione usando un backend Grails già esistente. Prima di iniziare a utilizzare il layout manager ho letto di Marionette e Chaplin ed entrambi mi sono sembrati davvero potenti ma complessi. Poi ho ricordato perché in origine ho scelto backbone.js: semplicità. Tutti questi framework aggiungono ciò che la struttura portante ha lasciato fuori dalla struttura. Non sto dicendo che un framework sia male, ma se ho bisogno di qualcosa di più complesso proverò altri progetti, come ember.js o sproutcore, dal momento che hanno una base di codice unica, scritta con un obiettivo nella mente dei loro sviluppatori. Qui abbiamo quadri sopra l'altro. Naturalmente, la spina dorsale è una spina dorsale non solo per la creazione di applicazioni, ma anche per la scrittura di alcune librerie più potenti, ma l'unica cosa che penso sia davvero scadente è il livello di visualizzazione, poiché manca un gestore di layout e la possibilità di nidificare le viste. Con il layout manager quel gap viene colmato abbastanza bene.

Quindi, la mia risposta alla tua domanda è: inizia dall'uso della spina dorsale così com'è e chiediti cosa manca e quali erano le tue aspettative sul framework. Se scopri che ci sono troppe cose escluse dalla spina dorsale, vai a cercarle negli altri framework e scegli quella più vicina alle tue esigenze. E se non sei ancora sicuro della scelta, forse la spina dorsale non fa per te e devi cercare qualche altra soluzione (ember.js, sproutcore, ExtJs, JavaScript MVC sono tutti buoni). Se hai esperienza nella scrittura di app client, non hai davvero bisogno di esperienza su tutto il framework là fuori per scegliere quello giusto (per te, ovviamente)


13

Ho studiato i vari framework creati con Backbone.js e costruito le vertebre per un progetto su HauteLook. Gli obiettivi del progetto includevano ... caricamento dinamico degli script, formato del modulo AMD, gestione delle dipendenze, compilazione con librerie prevalentemente open source, organizzazione del codice in pacchetti, ottimizzazione e creazione per una o più app a pagina singola, host su server completamente memorizzato nella cache, ad es. Nessun server lo scripting laterale che utilizza solo un'API per i dati, e il più divertente per me, utilizza lo sviluppo basato sul comportamento per il progetto. C'è una descrizione del progetto su: http://www.hautelooktech.com/2012/05/24/vertebrae-front-end-framework-built-with-backbone-js-and-requirejs-using-amd/

Il nostro problema:

Le librerie selezionate (jQuery, Underscore.js, Backbone.js, RequireJS, Moustache) forniscono il caricamento del modulo, la gestione delle dipendenze, la struttura dell'applicazione (per modelli, raccolte, viste e route), interazioni asincrone con l'API, varie utility e oggetti per gestire comportamenti asincroni , ad esempio (promesse) differiti, richiamate. La logica rimanente necessaria per completare il framework include:

  • un oggetto (modello) per gestire lo stato dell'applicazione a pagina singola;
  • un gestore di layout per presentare, organizzare / transizione e cancellare le viste, e
  • controller che rispondono ai percorsi, ottengono / impostano lo stato dell'applicazione e distribuiscono il lavoro al gestore del layout.

Le nostre soluzioni (implementate nelle vertebre):

Gestione dello stato dell'applicazione -

Il gestore dell'applicazione archivia i dati in memoria e persiste anche i dati nella memoria del browser per fornire una risorsa per dati / metadati comuni. Fornisce inoltre dati (stato) per ricostruire le visualizzazioni di pagina in base alle interazioni precedenti (ad es. Scheda selezionata, filtri applicati). Il gestore dello stato dell'applicazione fornisce una strategia per le risorse per recuperare lo stato. Avrebbe dovuto fungere da macchina statale.

Gestore layout -

Il gestore del layout ha una o più viste e destinazioni documento (DOM) per ciascuna vista (renderizzata). Una pagina può passare da una vista all'altra, quindi il gestore del layout tiene traccia degli stati della vista, ad es. Renderizzati, non renderizzati, visualizzati, non visualizzati. È possibile utilizzare il layout manager per caricare in modo pigro e rendere (distaccate) le visualizzazioni che è molto probabile che un visitatore del sito richieda, ad esempio modifiche alle schede in una pagina. La transizione tra gli stati di visualizzazione è gestita da questo oggetto. È possibile cancellare un intero layout in modo da rimuovere gli oggetti di visualizzazione e i relativi collegamenti, preparando questi oggetti per la garbage collection (evitando perdite di memoria). Il gestore del layout comunica inoltre lo stato di visualizzazione con i controller.

Controller -

Un oggetto controller viene chiamato da una funzione del gestore di route ed è responsabile di ottenere lo stato rilevante (modelli di applicazione) per generare una pagina (layout), (anche responsabile dell'impostazione dello stato quando le route cambiano). Il controller passa i dati dipendenti (modelli / raccolte) e costruisce gli oggetti vista per una pagina richiesta al gestore del layout. Come effetto collaterale, l'uso di controller impedisce all'oggetto route di gonfiarsi e ingarbugliarsi. Un percorso dovrebbe essere associato a un controller che avvia la visualizzazione della pagina, mantenendo snelle le funzioni di gestione del percorso.

L'app Todos è ospitata sia in modalità dev che ottimizzata su Heroku ...

Molti dei concetti negli altri framework sono presi in prestito, ad esempio la necessità di viste distruttive per visualizzare in anteprima le perdite di memoria, come sottolineato da Derick Bailey - http://lostechies.com/derickbailey/ ; il responsabile del layout di Tim Branyen http://tbranyen.github.com/backbone.layoutmanager/

In sintesi, Backbone.js è pensato per essere uno strumento nell'applicazione, la libreria Backbone.js non fornisce tutta l'architettura necessaria per creare un'applicazione, ma fornisce ottime interazioni con un'API e una struttura di codice solido per ... Viste (anche come controller) e modelli e raccolte del livello dati, e infine Percorsi. Abbiamo costruito le vertebre per dare impulso agli obiettivi del nostro progetto e abbiamo deciso di estrarre il codice come framework da usare, apprendere o quant'altro.

La risposta alla tua domanda secondo me è quella di imparare da tutti i framework e usare ciò di cui hai bisogno per raggiungere i tuoi obiettivi, se trovi che gli obiettivi del tuo progetto si adattano strettamente a uno dei framework creati con Backbone, allora fantastico, altrimenti costruisci il tuo framework ci sono ottimi esempi condivisi dalla comunità. O se ti ritrovi un po 'perso nella direzione della tua applicazione, scegli qualcosa di più supponente e strutturato forse Ember.js. La cosa fantastica è che ci sono un buon assortimento di scelte per aiutarti a programmare usando un modello MVC (MVX) come JavaScript.


Grazie per la risposta dettagliata
Danikoren,

13

Ho sviluppato il framework Luca mentre lavoravo a BenchPrep dove lo abbiamo utilizzato per sviluppare diverse app di grandi dimensioni a pagina singola in cima alla libreria backbone.js.

Avevo lavorato con ExtJS per diversi anni prima e ho rubato i miei concetti preferiti da quel framework come l'architettura basata sui componenti in cui sviluppate le vostre viste come componenti autonomi e poi li unite ad altri componenti usando le viste contenitore. E poiché è fortemente basato sulla configurazione, lo sviluppo di un'app in Luca sembra molto simile alla descrizione di un oggetto con JSON.

Un vantaggio di questo approccio è la possibilità di riutilizzare i componenti in più app o in luoghi diversi della tua app, con solo lievi modifiche usando l'estensione di Backbone. È anche molto semplice sperimentare molti layout / presentazioni di componenti diversi apportando solo piccole modifiche alla configurazione JSON.

Oltre a una vasta gamma di funzioni helper / utility, Luca viene fornito con molti derivati ​​Backbone di livello superiore che è possibile mettere insieme in qualsiasi modo immaginabile per creare un'interfaccia utente complessa.

Viste, componenti, contenitori

  • Classi di modello, vista, collezione, router aumentate
  • Opzioni di configurazione che facilitano la comunicazione tra modelli, raccolte, viste, l'applicazione e i rispettivi gestori.
  • Contenitori (Layout diviso / colonna, Layout griglia, Vista scheda, Vista scheda / procedura guidata)
  • FormView con tutti i componenti di campo standard e gli helper per la sincronizzazione con un Backbone.Model
  • GridView, per generare elementi griglia scorrevoli da un Luca.Collection
  • CollectionView, per generare viste basate su una raccolta
  • Barre degli strumenti / pulsanti

Stili e markup Bootstrap di Twitter gratuiti

  • Luca gioca molto bene con il framework di bootstrap di Twitter. Semplicemente impostando Luca.enableBootstrap = true e includendo il CSS, i tuoi componenti (come le schede, le barre degli strumenti, i pulsanti, i moduli, i campi, le griglie, ecc.) Useranno automaticamente il markup compatibile Twitter Bootstrap e le convenzioni di classe CSS.
  • Utilizza il sistema Grid per il layout e risponde alla maggior parte delle classi css di bootstrap in modo intelligente
  • I componenti Luca.Viewport e GridLayout sono configurati per funzionare con i sistemi a griglia reattiva, fluida o statica di bootstrap.
  • Mira a fornire una corrispondenza uno a uno per i componenti Twitter Bootstrap, per rappresentarli come viste Backbone configurabili

Il componente dell'applicazione

  • La macchina a stati basata su Backbone.Model fornisce metodi getter / setter e attribuisce eventi di modifica come uno stile del flusso di controllo dell'applicazione
  • Componente del controller integrato che nasconde / mostra le pagine dell'app in risposta agli eventi Backbone.Router o State Machine
  • Integrated Collection Manager che tiene traccia delle raccolte che hai creato, ti consente di ambito, raggrupparli, assegnare loro i parametri predefiniti
  • Un gestore socket che è un livello di astrazione in cima ai servizi WebSocket che rende la spinta facile come Backbone.Event
  • Un router per eventi da tastiera che attiva eventi chiave denominati su componenti che desiderano rispondere a tali eventi

Miglioramenti alla raccolta e al modello

  • Le raccolte si basano su backbone-query , che fornisce un'interfaccia di query molto simile a mongoDb
  • abilitare un archivio locale Backbone.sync semplicemente impostando collection.localStorage = true
  • popolamento automatico di raccolte i cui dati sono avviati al caricamento della pagina
  • metodi memorizzati nella cache / proprietà calcolate. memorizza nella cache il risultato dei metodi di raccolta e scade la cache in risposta alla modifica / aggiunta / rimozione di eventi sulla raccolta o sui suoi modelli
  • proprietà calcolate sui modelli. costruire attributi basati su funzioni complesse e aggiornare automaticamente il valore calcolato in risposta alle modifiche

Eventi e ganci

I componenti di Luca sono più liberali con gli eventi che emettono rispetto ai componenti Backbone di serie. Emetteranno eventi come prima: inizializza, dopo: inizializza, prima: rendering, dopo: rendering, attivazione, prima: attivazione, disattivazione, prima: disattivazione, e questo ti consente di ottimizzare il comportamento dei tuoi componenti. Inoltre, definendo un evento nella porzione di @hooks a tuo avviso, chiamerà automaticamente una funzione con nome simile se esiste. Ciò impedisce molto codice di stile di callback che migliora la leggibilità.

È inoltre possibile configurare la classe Luca.Events per pubblicare gli eventi su un canale globale di pubblicazione / sottoscrizione, il che semplifica la creazione di un'applicazione di grandi dimensioni e facilita la comunicazione tra moduli.

La gemma di rubino

Luca è stato sviluppato specificatamente mentre lavora contro le API di Rails e Sinatra e per questo è attualmente ottimizzato per uno stack specifico, ma non ti blocca in alcun modo in un server specifico.

Luca viene distribuito come parte di una gemma di Ruby configurata per funzionare sulla pipeline delle risorse o come file JS scaricabile.

Non è necessario utilizzare Rails o Sinatra. Ma se lo fai, ho incluso molte cose utili:

  • I file con estensione .luca vengono elaborati come HAML con interpolazione variabile in stile JST. (equivalente a .jst.ejs.haml) dalla pipeline delle attività
  • Un cablaggio di prova per browser o test unitari basati su Jasmine senza testa insieme a molti helper di test Backbone e Underscore.
  • Un endpoint API per il set di strumenti di sviluppo fornito con Luca (ne parleremo più avanti)
  • Un endpoint API che consente di utilizzare Redis come motore di archiviazione schematico per Luca.Collection con una configurazione minima

Gli strumenti di sviluppo

  • Le applicazioni Luca possono abilitare una console caffè nel browser con aiutanti e comandi specifici di Luca che aiutano a monitorare, ispezionare, eseguire il debug di applicazioni e componenti Luca

Un esempio di Luca nella console di sviluppo del browser basata su CoffeeScript

  • Con l'aiuto di Rails Gem e dell'editor dei componenti basato su CodeMirror di Luca, puoi modificare il codice sorgente di Luca Framework e i componenti specifici dell'applicazione direttamente nel browser, usando Coffeescript. Vedrai un feedback immediato in risposta alle tue modifiche, con le istanze di oggetti interessati che verranno aggiornate con il prototipo aggiornato e potrai salvare le tue modifiche su disco.

  • Component Tester è un sandbox live per giocare con i componenti che compongono la tua applicazione in modo isolato. Fornisce strumenti per modificare il prototipo del componente, impostarne le dipendenze e configurare il componente. Il componente eseguirà nuovamente il rendering immediatamente ogni volta che si effettua una modifica. È possibile visualizzare e modificare il markup generato dal componente, nonché il CSS direttamente nel browser e visualizzare immediatamente le modifiche. Questo lo rende uno strumento di sperimentazione molto prezioso.

  • Component Tester si integrerà presto con Jasmine in modo da poter visualizzare i risultati dei test delle unità componenti in tempo reale mentre si modifica il loro codice

Uno screenshot del tester componente

Luca è in fase di elaborazione, ma mantiene un'API stabile (non ancora 1.0) ed è stato utilizzato in diverse app di produzione di grandi dimensioni. È sicuramente un framework molto ponderato, ma sto lavorando per renderlo più modulare. Sto lavorando attivamente alla documentazione e ai componenti di esempio.


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.