Is it a good design, when a React Flux store emits multiple kinds of events?

Question

Almost all tutorials I found about flux emits only one event per store (emitChange). I don't really know, that it is intentional, or just the consequence of the tutorials simplicity.

I try to implement a store, that corresponds to the CRUD architecture, and I'm wondering if it would be a good design decision to emit different events for each CRUD method.

The relevant part of one of my stores look like this:

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
});

If my approach is wrong, how would I tell my components the type of event, that happend (for example: delete or update)

Answer 1

Flux as a design pattern is built on top of the idea that all data resides in "stores". Each store holds data for a given domain of information. As an example: in Flux, all comments would reside in a CommentStore.

When data is changed in a store, it should emit an event and all components that builds on top of this "information domain", should rerender and display the new domain data.

I've found that when a store is emitting multiple event types, it is more likely that components are not listening for that specific event, thus not rerendering itself when the domains data is altered.

This breaks the whole flux-pattern, and can easily create hard to find bugs where components are out of sync with the stores information.

I would instead recommend that you design your components from the "Law of Demeter" - each component should only know as much as it needs to.

So instead of the component listening to an event that says "commentList has been updated", you should create a commentListComponent that listens on a single store event. Thus, the component will listen on commentStore.on('change') - I usually let all stores emit an 'change' event. When the store emitts, you should rerender the data in the commenListComponent to reflect the store. If you use React, this is where you use 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>
    }
})

This makes the data flow much more simple, and avoids hard to spot errors.