Это хороший дизайн, когда хранилище React Flux испускает несколько видов событий?

Почти все обучающие материалы, которые я нашел о потоке, испускают только одно событие в хранилище (emitChange). Я действительно не знаю, что это намеренно или просто следствие простоты учебников.

Я пытаюсь реализовать хранилище, соответствующее архитектуре CRUD, и мне интересно, будет ли это хорошим дизайнерским решением испускать разные события для каждого метода CRUD.

Соответствующая часть одного из моих магазинов выглядит следующим образом:

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

Если мой подход неверен, как я могу сообщить моим компонентам тип события, которое произошло (например: удалить или обновить)

Ответы

Ответ 1

Flux как шаблон дизайна строится поверх идеи о том, что все данные хранятся в "магазинах". Каждый магазин хранит данные для данного домена информации. В качестве примера: в Flux все комментарии будут размещаться в блоке CommentStore.

Когда данные изменяются в хранилище, он должен испускать событие, а все компоненты, которые строятся поверх этого "информационного домена", должны воспроизводить и отображать новые данные домена.

Я обнаружил, что, когда хранилище испускает несколько типов событий, более вероятно, что компоненты не прослушивают это конкретное событие, поэтому не реиндексируют себя, когда данные домена изменены.

Это разбивает весь шаблон потока и может легко создавать трудно найти ошибки, когда компоненты не синхронизируются с информацией о магазинах.

Вместо этого я рекомендовал бы, чтобы вы разработали свои компоненты из "Закона Деметры" - каждый компонент должен знать только столько, сколько ему нужно.

Поэтому вместо компонента, слушающего событие, в котором говорится, что "commentList был обновлен", вы должны создать комментарийListComponent, который прослушивает одно событие хранилища. Таким образом, компонент будет прослушивать commentStore.on('change') - я обычно позволяю всем магазинам выпускать событие "change". Когда хранилище эмитирует, вы должны перерегистрировать данные в commenListComponent, чтобы отразить хранилище. Если вы используете React, здесь вы используете 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>
    }
})

Это делает поток данных более простым и позволяет избежать затруднений при обнаружении ошибок.

Ответ 2

Мой прецедент заставляет меня использовать разные события. У меня есть компонент карты, который отображает множество сложных объектов, и было бы очень дорого обновлять каждый.

EventEmitter2 реализует многоуровневые и групповые события. Это позволяет мне слушать события "изменения", а точнее, события под-уровня "change.add" "change.remove"...

this.emit("change.add");

может прослушиваться

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

Таким образом, многие из моих компонентов могут просто прослушивать событие "change. *". И более сложные компоненты, нуждающиеся в оптимизации, могут прослушивать определенные события.

Лучшее из обоих миров

PS: не забудьте включить подстановочные знаки. См. Документацию