È un buon design, quando un negozio React Flux emette più tipi di eventi?

Question

Quasi tutte le esercitazioni che ho trovato sul flusso emettono solo un evento per negozio (emitChange). Non so davvero, che sia intenzionale, o solo la conseguenza della semplicità delle esercitazioni.

Cerco di implementare un negozio, che corrisponde all'architettura CRUD, e mi chiedo se sarebbe una buona decisione progettuale emettere eventi diversi per ogni metodo CRUD.

La parte rilevante di uno dei miei negozi simile a questa:

var UserStore = _.extend({}, EventEmitter.prototype, { 

    emitChange: function() { 
     this.emit('change'); 
    }, 

    emitUserAdded: function() { 
     this.emit('userAdded'); 
    }, 

    emitUserUpdated: function() { 
     this.emit('userUpdated'); 
    }, 

    emitUserDeleted: function() { 
     this.emit('userDeleted'); 
    }, 

    // addListener, removeListener in the same manner 
}); 

Se il mio approccio è sbagliato, come avrei dico ai miei componenti il ​​tipo di evento, quello accadesse (ad esempio: cancellazione o l'aggiornamento)

Answer 1

Il flusso come modello di progettazione si basa sull'idea che tutti i dati risiedano in "negozi". Ogni negozio contiene dati per un dato dominio di informazioni. Ad esempio: in Flux, tutti i commenti dovrebbero risiedere in un CommentStore.

Quando i dati vengono modificati in un negozio, è necessario emettere un evento e tutti i componenti che si sviluppano sopra questo "dominio delle informazioni", devono eseguire nuovamente il rerender e visualizzare i nuovi dati del dominio.

Ho scoperto che quando un negozio emette più tipi di eventi, è più probabile che i componenti non ascoltino quell'evento specifico, quindi non si riorganizzano quando i dati dei domini vengono modificati.

Questo interrompe l'intero schema di flusso e può facilmente creare bug difficili da trovare dove i componenti non sono sincronizzati con le informazioni del negozio.

Vorrei invece consigliare di progettare i componenti dalla "Legge di Demeter" - ogni componente dovrebbe solo sapere quanto necessario.

Quindi, anziché il componente che ascolta un evento che dice "commentList è stato aggiornato", è necessario creare un componente CommentList che ascolti un evento di un singolo negozio. Quindi, il componente ascolterà su commentStore.on ('cambia') - Di solito permetto a tutti i negozi di emettere un evento 'change'. Quando il negozio emette, è necessario rileggere i dati nel commenListComponent per riflettere lo store. Se si utilizza React, questo è dove si usa setState.

var commentStore = _.extend({}, EventEmitter.prototype, { 

updateComents: function() { 
    // Update comments and emit 
    this.emit('change'); 
}, 

removeComments: function() { 
    // Remove comments and emit 
    this.emit('change'); 
}, 

getState: function() { 
    return { 
     comments: this.comments, 
     someOtherDomainData: this.meta, 
    } 
} 
}); 

//commentListComponent.js 
var commentListComponent = React.createClass({ 
    componentDidMount : function() { 
     commentStore.on('change', this._commentChanged); 
    }, 
    componentWillUnmount : function() { 
     commentStore.off('change', this._commentChanged); 
    }, 
    _commentChanged : function() { 
     this.setState({ comments : commentStore.getState().comments }); 
    }, 
    render : function() { 
     var comments = // Build a list of comments. 
     return <div>{comments}</div> 
    } 
}) 

Questo rende il flusso dei dati molto più semplice ed evita errori di difficile individuazione.

Answer 2

Il mio caso d'uso mi obbliga a utilizzare eventi distinti. Ho un componente di mappa che mostra molti oggetti complessi e sarebbe molto costoso aggiornarli.

EventEmitter2 implementa eventi multilivello e caratteri jolly. Mi permette di ascoltare gli eventi "cambiamento", o più precisamente gli eventi sub-livello "change.add" "change.remove" ...

this.emit("change.add"); 

può essere in ascolto da

myStore.on('change.*', callback); 
myStore.on('change.add', callback); 

In questo in questo modo, molti dei miei componenti possono semplicemente ascoltare l'evento "change. *". E i componenti più complessi che necessitano di ottimizzazione possono ascoltare eventi specifici.

Il meglio dei due mondi

PS: non dimenticate di abilitare i caratteri jolly.Vedere la documentazione