Rendere accessibile un messaggio flash di reazione globalmente rompere qualsiasi convenzione?

Question

Rendere accessibile un messaggio flash di reazione globalmente rompere qualsiasi convenzione?

#1 da (2 voti)
#2 da (2 voti)

1

Ho letto questo articolo in cui descrive la creazione di un messaggio flash in un'app di risposta:

Esse menzionano l'aggiunta di un riferimento nell'oggetto window all'oggetto FlashMessages . In questo modo puoi accedere all'oggetto FlashMessages da qualsiasi punto dell'app e aggiungere un nuovo messaggio flash.

// within the FlashMessages constructor
window.flash_messages = this

//In some other object
window.flash_messages.addMessage('Some message')

Da una parte, questo sembra il tipo di cosa che vorresti aggiungere globalmente, ma dall'altra sembra spezzare il modello che React tende a sposare, ovvero mantenere le cose isolate in un componente. Questa rottura è una best practice?

javascript reactjs

posta unflores 26.04.2017 - 21:40

fonte

2 risposte

2

Non sono affatto un esperto in JS o React.js Devo essere d'accordo sul fatto che rendere le variabili globalmente disponibili sia molto rischioso. È un progetto solista. Quindi in una certa misura il rischio è limitato.

Senza sapere che il tuo progetto è lì fuori puoi creare una funzione / metodo / modulo che crea il messaggio flash e limitare le variabili in quello locale. Rendere il modulo stesso globalmente disponibile attraverso la creazione di un oggetto.

Fammi sapere come funziona.

risposta data 27.04.2017 - 10:44

fonte

Leggi altre domande sui tag javascript reactjs

Custom CSS Framework Ridimensionamento dell'approccio alla riprogettazione?

score 2 · Accepted Answer

L'esposizione di this di un componente React non è una best practice. Mentre funziona, ci sono modi più desiderabili per svolgere le stesse attività. Se si tiene conto di un'istanza di this , il riferimento potrebbe diventare obsoleto se il componente viene rimontato. Inoltre, poiché non è una buona pratica, poiché React si evolve, potrebbe diventare più problematico.

Un'applicazione React tenta di incapsulare tutto il suo stato, in modo che ciò che viene reso è prevedibile. Una parte importante di React è che il flusso di dati è generalmente facile da seguire: gli eventi attivano setState , i dati scorrono, viene reso un nuovo albero.

Da quanto ho capito in questa situazione, ci sono due possibili percorsi per flash_messages :

Il server restituisce flash_messages prima che sia stata inviata la risposta HTTP o
Un bridge Rails-JS sta inviando flash_messages tramite XHR all'app senza eseguire l'aggiornamento.

Nel primo caso, quando viene montata la nostra app React, può consumare questi messaggi flash al momento della costruzione e propagare di conseguenza lo sate. Non è necessario che il codice esterno si interfaccia con React: React può solo leggere flash_messages e fare ciò di cui ha bisogno.

Nel secondo caso, l'approccio migliore è che Rails-JS espone un'interfaccia listener. Quindi, al momento della costruzione di React, puoi iscriverti agli eventi, chiamando di conseguenza setState .

In sintesi: è meglio per React iscriversi agli eventi e aggiornare il suo stato quando necessario, invece del codice esterno che fa riferimento a this di un oggetto.