Design Patterns for a Rails 3.2 JS-heavy App

Question

Sto lavorando su una nuova applicazione di gestione delle 3.2 guide che fa molto affidamento sui dati JSON (risultati di completamento automatico, eventi del calendario, attività, manipolazione dinamica dei moduli, ecc.). Il sistema di backend è già abbastanza solido, quindi stiamo investendo nella parte dell'interfaccia utente e vogliamo renderlo più simile a webapp, rispecchiando il comportamento di altre app "fat client" come quelle di Google. Per raggiungere questo obiettivo, quale sarebbe il miglior schema di progettazione: utilizzando un framework MVC JS come Backbone.js, delegando così una buona parte della manipolazione dei dati all'interfaccia utente e l'interfaccia con il nostro API JSON, o lavorando con JS remoto (es. js.erb templates), che consente un maggior uso del codice Ruby?

Stiamo già utilizzando Backbone.js in modo molto rozzo in alcune visualizzazioni, ma sembra che il precedente approccio utilizzi molte risorse sviluppate poiché JS è più difficile da codificare e abbiamo l'onere aggiuntivo di eseguire il mirroring di alcuni codici di modello nell'interfaccia utente , pur essendo molto più reattivo per l'utente finale. Quest'ultimo approccio consente un codice View più snello a scapito dei tempi di risposta e, tutto sommato, non sembra giusto, ma è sicuramente più veloce da sviluppare e più flessibile.

Tenendo presente che siamo una piccola squadra con un sacco di esperienza Rails e non tanto in JS/Coffeescript/Backbone.js e abbiamo una scadenza vicina per incontrarsi, quale approccio scegliereste? La ragione per cui sono in perdita in questo è che la nostra azienda è orgogliosa della qualità del nostro codice e dell'aderenza ai modelli di design moderni, quindi non posso fare a meno di pensare che, nonostante i suoi punti di forza, l'utilizzo di JS remoto sembra un ' cattiva scorciatoia ', quindi apprezzerei molto l'input da voi ragazzi. Forse sono solo di parte.

Answer 1

Beh, non posso decidere per voi, che dipende principalmente da quanto è vicina la scadenza ma preferisco personalmente l'approccio Backbone.js.

Se devo discutere, posso dire che avrete uno script JS statico e memorizzabile nella cache e accenderete richieste AJAX (solo JSON), mentre con l'altro approccio avrete download di script più pesanti e non memorizzabili nella cache.

Ma soprattutto credo che il metodo Backbone sia l'approccio migliore per rendere il vostro codice organizzato e mantenibile.

1. Coffeescript è fantastico e molto veloce da imparare. Semplifica molto la sintassi JS e lo rende divertente. Vale la pena provare. Imparato in 30 minuti.

2. Backbone.js è fantastico e veloce da imparare. L'utilizzo di questo approccio ti consentirà di fare affidamento sugli eventi, che è molto più pulito di quello a cui possiamo fare a meno.

   Grazie alla pipeline delle risorse, è possibile dividere le viste/modelli/classe di router in file separati, il che è molto bello.

   Grazie ad CoffeeScript potete scrivere i vostri oggetti backbone con una sintassi molto pulita come quella:

   class @MyView extends Backbone.View 
       events: 
       'click obj': 'handler' 
       [...] 
   

   Con questo aggiungo nei miei progetti un po '@module aiuto per organizzare i miei oggetti in spazi dei nomi.

Tuttavia, ci vorrà del tempo per trovare la buona organizzazione dei file.

È possibile iniziare con gem rails-backbone e disporre di alcuni generatori simili ai binari. Non mi piace per niente, ma penso che sia un buon inizio. Include una funzione Backbone.sync adattata alle guide.

Modifica

Ecco alcuni dettagli circa il @module aiutante. Includo questo application.js.coffee (non dimenticate di require_self):

@module = (names, fn) -> 
    names = names.split '.' if typeof names is 'string' 
    space = @[names.shift()] ||= {} 
    space.module ||= @module 
    if names.length 
    space.module names, fn 
    else 
    fn.call space 

Nei miei file di classe:

@module 'MyProject.Model', -> 
    class @MyModel extends Backbone.Model 
    [...] 

(Si noti che @ è la scorciatoia per CoffeeScript this..)

Il l'helper crea oggetti MyProject e MyProject.Model se necessario (se null) ed esegue la funzione data con this binding a MyProject.Model. Così si può accedere al modello del genere da spazio dei nomi root (document):

m = new MyProject.Model.MyModel 

È inoltre possibile embricate l'helper:

@module 'MyProject', -> 
    @module 'Model', -> 
    [...] 

Io uso la gerarchia seguenti spazi dei nomi

MyProject 
    Model 
    View 
    Router 
    Runtime (to store all runtimes objects and don't pollute the root namespace, easier for debug)