Perché gli smart che scrivono e adottano react.js sono a posto con il modo in cui il markup è strettamente collegato / sepolto all'interno di Javascript?

Sono anche cresciuto MVC. Credo che avremo bisogno di immergerci in FLUX per capire il quadro completo.

La mia comprensione è che come modello HTML spostato nel browser (con framework Backbone o Angular), questa applicazione a una sola pagina può fornire una migliore esperienza interattiva per l'utente rispetto all'app Web tradizionale con manomissione lato server. Ad esempio, l'applicazione può contenere lo stato dell'applicazione e basarsi su alcuni aggiornamenti dell'azione utente vari elementi HTML istantaneamente senza round trip al server.

Ma lo stato di gestione si è rivelato complicato con Backbone o Angular 1.x (non sono sicuro di come Angular 2 lo gestisce finora), perché modelli MVC o MVx accoppiano il modello dati con la vista tramite controller o direttamente . Ma cosa succede se si desidera reagire in altre viste sul cambiamento di stato di questo modello? Angular 1 offre alcune funzionalità per la gestione di questo, ma puoi facilmente spararti a piedi con i controller nidificati o l'ambito nidificato.

Quindi movimento FLUX sta cercando di risolvere questo problema e ha introdotto questo flusso unidirezionale:

---- > Dispatcher ---- > State Store ------ > Componente (Visualizza) ----- > Dispatcher

Il componente oi vari componenti sono iscritti a determinate modifiche allo stato del modello e invia le azioni dell'utente a Dispatcher . Dispatcher basato su queste azioni aggiorna il modello (archivio di stato) , che può attivare nuovamente uno o più aggiornamenti di visualizzazione . L'azione del dispatcher non deve essere attivata dal solo componente. Può essere fatto anche dal server. In questo modo la condivisione dello stato (modelli) tra le viste è molto più semplice.

Ora React.JS è un componente del diagramma sopra. La parte fondamentale è che non muta direttamente DOM, ma usa il concetto di shadow DOM, dove raccoglie le differenze rispetto al precedente stato DOM e le applica solo loro. Così puoi ri-renderizzare molto o anche tutti i tuoi componenti, senza preoccuparti soprattutto delle prestazioni.

La conseguenza di tutto questo è che il componente React ha questi problemi:

• È necessario utilizzare Shadow DOM per mutare HTML
• È necessario sottoscrivere modifiche al modello (State Store)
• È necessario inviare azioni contro State Store

Se si mescolano tutti questi problemi in un singolo componente, si ottiene JavaScript sepolto all'interno del modello come si è scritto. Sono stato anche inorridito da questo quando ho iniziato a esaminare queste aree di sviluppo dell'interfaccia utente.

L'ecosistema reattivo si sta evolvendo rapidamente e ci sono tentativi di migliorarlo. Per esempio guarda come Dan Abramov (creatore di una delle librerie di State Store più hot chiamata Redux) separa questi preoccupazioni nei cosiddetti tipi di componenti Presentational e Container .

Quindi lunga storia , all'inizio sembra un passo indietro, ma se ti immergi più a fondo, potresti ottenere benefici di manutenibilità molto più grandi a lungo termine in forma di vero modello di disaccoppiamento dalla vista.

BTW, ti consiglio di controllare questo video su FLUX vs MVC .

Un punto importante da comprendere è che non si scrivono modelli tradizionali basati su stringhe. JSX è solo uno zucchero di sintassi per creare un semplice oggetto javascript. Ti offre analisi statiche e capacità di test unitario. È piuttosto una differenza rispetto ai precedenti tentativi di mixare codice e markup.

Come già sottolineato con componenti funzionali che sono semplici funzioni javascript che accettano argomenti (oggetti di scena) e restituiscono JSX puoi disaccoppiare la vista dalla logica come desideri e tenerli in file separati, anche in un modulo NPM separato puoi facilmente condividi nei tuoi progetti.

Se lo confronti, ad es. a Angular2, aggancia il modello usando la decorazione. React lo aggancia nel suo metodo render che può eseguire il rendering di un singolo componente della vista che successivamente rende il resto dell'albero della vista senza una logica di stato. Quindi non c'è molta differenza. In realtà qualcuno potrebbe elaborare qualche differenza pratica?

Se ci pensi, qual è il vantaggio del template basato su stringhe che ha possibilità limitate per l'analisi statica, è difficile testare se effettivamente possibile senza test E2E e richiede un linguaggio di template proprietario? Solo errori stupidi nei gestori di eventi con hook e simili.

Per creare "template" di React, ho bisogno solo di javascript che va bene per questo scopo con le funzionalità di ES6. Ma alcuni potrebbero preferire un linguaggio specializzato, in alcuni casi dà più concisione.

Angular 1.x non è HTML perché il suo HTML è pesantemente annotato con direttive proprietarie che devono essere analizzate nel browser e convertite in HTML effettivo.

Qual è il vantaggio di mettere JS in HTML, il che significa mettere code di codice nella stringa? HTML è meno potente di JS. Cosa c'è di sbagliato in un'idea per controllare HTML meno potente da JS più potente? Soprattutto quando puoi mettere quanti indizi indiretti vuoi.

Imparare JSX è un modo per realizzare l'uso di className e htmlFor e imparare l'escape di '{}'. Se non si desidera eseguire la componentizzazione, è possibile copiare in copia semplice html normale e bulk find / replace sopra 2 argomenti (possibilmente alcuni di più). Come vantaggio, è molto semplice definire pattern ripetuti come componenti per definire l'aspetto e l'aspetto delle app:

// ES6, advantage is you see props requirements from function signature
const Button = ({labelText, ...some more}) => (
  ... your "markup" ...
}

// ES5
function Button(props) {
  return (
   ... your "markup" using props.labelText...
  )
}

Qualcuno è in grado di sintetizzare il motivo per cui i tentativi precedenti di mescolare codice e marcatura falliscono? React ha le stesse limitazioni?