Newsgroup: it.comp.lang.javascript
Titolo: React/Flux - Backbone - Router - Unit Testing

Ciao a tutti,
 
 
stiamo iniziando ad implementare una SPA che si interfaccia con un 
backend che espone API REST.
 
Per il frontend abbiam scelto di usare ReactJs e volevamo implementare il 
tutto seguendo il pattern FLUX (chiaro ma non chiarissimo).
 
L'utilizzo di browserify ci permette di modularizzare il tutto meglio 
almeno nel frontend e di utilizzare gran parte degli npm disponibili 
(nota di colore: sono stato quasi scarnificato vivo quando ho proposto di 
passare a nodejs come backend)
 
 
La prima domanda a chi e' piu esperto di me e' se abbia senso utilizzare 
backbone (model/collections) negli store perche' ho letto molte opinioni 
contrastanti perche' si espongono gli store ad essere modificati 
direttamente senza passare dal dispatcher
 
 
 
Per il routing avete qualche suggerimento? a parte il router di backbone 
ho trovato molto interessante react-router
 
 
Cosa utlizzate per unit test?
 
 
Come ciclo di sviluppo abbiam pensato a qualcosa del genere
 
1 folder con jsx
2 jsx --watch compila dentro al folder js
3 watchify compila --debug in app-debug.js
4 app-debug.js viene incluso dentro index-debug.html
 
per il rilascio
 
1 browserify compila il folder js
2 uglify minimizza il tutto
3 include dentro index.html il js minimizzato
 
che ne pensate, puo' essere migliorato/ottimizzato/rivoluzionato?
 
 
 
 
 
 
 
 
-- 
Jeff

) come base per tutti i task.
 
Mi è sembrato *molto* più maneggevole del suo famoso predecessore grunt 
e ci sono già "wrapper" precotti per tutto: browserify, minificazione, 
source maps e chi più ne ha più ne metta.
 
Lavorando con gli stream è molto facile togliere un pezzo o incastrarne 
un altro alla bisogna.
 
 
 

 
 
e questa cosa cosa sarebbe? :o
 
 
-- 
Jeff

 Si lo ho visto, ma non arrivo a comprenderne la vera utilita'
 
Be`, in generale, evitare che lo stato di un oggetto venga modificato durante una serie di chiamate e` sempre una buona cosa, anche perche` potrebbe lasciare l'oggetto in uno stato inconsistente se ci sono eccezioni. Ci sono scuole di pensiero (come in Effective Java di Joshua Bloch) che vogliono che le classi siano sempre "immutable" o la loro mutabilita` sia sempre limitata per quanto possibile.


Anche senza tirare in ballo eccezioni, è bello sentirsi tranquilli 
mandando in giro dati ad altri pezzi di programma.
 
Senza contare che ti invita (forza) a impostare il flusso dati in una 
maniera più ordinata, sicura e meno prona a errori umani.
 
Altra chicca nel mezzo sono le Lazy Seq.
 
Jeff: credo che il readme del repository ti possa mettere sul piede 
giusto per approfondire.
 

 [...]
 
La mia domanda era leggermente diversa.
Una volta scaricati i dati dal server dove li salvo?
 
 
Intendo dire che non vorrei scaricarmi i dati dal server ogni volta che 
ho bisogno di accedere allo stesso data-set, ma lo aggiornerei via JS e 
aggiornerei via AJAX il dataset nel server remoto. 
 
(Tra l'altro e' quello che fa l'esempio del ToDO list che si tiene i dati 
locali dentro un array).
 
Quindi la mia domanda era se avete alcun suggerimento in modo da 
sostituire il plain array con qualcosa di piu' alto livello (tipo 
backbone model/collection dentro gli store), magari sto semplicemente 
chiedendo cose senza senso ma per un applicazione che e' oltre la todo 
list bisogna pensare anche come organizzare il data layer o no?
 
Per esempio supponiamo di avere un CMS builder, ho bisogno di avere tutti 
i layout disponibili, tutti i componenti disponibili, la lista delle 
pagine gia' create eccetera.
 
Per esempio ho la lista dei componenti devo poter accederla sia ogni 
volta che la stampo, sia ogni volta che salvo la pagina (perche' se u 
utente sceglie di mettere un componente in una pagina mi salvo il 
riferimento, per esempio)
 
E' possibili che mi stia sfuggendo come fare ste cose in Flux, ma cosi' a 
sentimento Flux diventa molto piu' utilie man mano che l'applicazione 
diventa piu' complessa.
 
 
-- 
Jeff

 list bisogna pensare anche come organizzare il data layer o no?
 
Ripeto che non ho ancora esperienza diretta con Flux, ma a me non 
verrebbe proprio di infilare i model / collection di backbone lì in 
mezzo: c'è il grosso rischio di andare a rompere il flusso 
unidirezionale di flux (e allora tanto vale non adottarlo) in favore di 
non so quale beneficio.
 
Io partirei da un altro punto di vista: quali funzionalità hanno questi 
model / collection di cui sentiresti la mancanza non usandoli?
 
 
 

 model / collection di cui sentiresti la mancanza non usandoli?
 
 
getter and setter in primis poi save/isnew/haschanged, il push/pull/where 
nelle collection oltre al fatto che sono  diffusi quindi molti 
sviluppatori gia' li conoscono.
 
L'altra idea e' creare l'oggetto backbone dentro allo store ed esportare 
lo store come modulo non esponendo backbone (in questo modo dovrebbe 
essere piu' difficile rompere il fluxo canalizzato - [peggior battuta 
dell'anno ma quanno ci vuole la citazione, ci vuole])
 
 
In verita' in prima istanza avremmo usato anche il router di backbone, ma 
ora lo abbiamo cambiato con react-router [anche se l'integrazione con il 
pattern flux non e' del tutto immediata]
 
 
 
 
 
-- 
Jeff

 pattern flux non e' del tutto immediata]
 
Appena mi decido a metterci mano ne discutiamo volentieri!
 
 

On Wed, 25 Feb 2015 08:46:23 +0100, Andrea Scartabelli scrisse:

Ho lasciato passare un po' di tempo, abbiamo iniziato l'implementazione.
 
Store e backbone.
Non necessario - non lo abbiamo implementato di default, ma non e' il 
male quindi lasciamo la scelta al singolo sviluppatore che ovviamente 
pero' non dove spaccare il pattern FLUX.
Usiamo invece underscore.
 
Ma giuro che siamo rimasti esterrefatti dalla velocita' dello sviluppo 
una volta digerito il pattern, molto molto piu' spedita e scorrevole di 
prima (era JS/PHP a cowboy).
 
 
 
 
 
-- 
Jeff

 prima (era JS/PHP a cowboy).
 
Bene, bravi, bis!
 
E ora bisogna che mi racconti prima di tutto cosa hai scelto per il 
routing e come ti sei trovato, poi, son curioso, come è stato pensato il 
layer che accede alle API del server.
 
Per essere più preciso facciamo finta che sia REST + JSON un lato: a me 
interessa l'altro; ovvero il layer che si occupa della comunicazione 
HTTP e immettere i dati nel flusso... Flux.