我正在开始一个新项目,我希望尽可能保持我的代码结构。我计划在前端使用磁通模式,但感觉就像磁通跟随的事件驱动过程一样,违背了流星处理数据和查看更新的反动方式。
这是我的一个商店使用flux和meteor看起来像什么的一个例子
import { EventEmitter } from 'events'
import appDispatcher from '../Dispatcher'
import Meteor from 'meteor/meteor'
class TaskStore extends EventEmitter {
constructor() {
super();
this.tasks = [];
Meteor.subscribe('tasks');
}
addTask(task) {
Meteor.addTask(task)
this.tasks = Meteor.findAll();
}
getTasks() {
return this.tasks
}
}
const taskStore = new TaskStore();
appDispatcher.register((payload) => {
switch (payload.actionName) {
case 'CLICK':
taskStore.addTask(payload.newItem.action);
taskStore.emit('ADD_TASK');
break;
default:
}
});
export default taskStore
这很简单,商店通过向mongo数据库添加任务来响应调度程序,然后使用数据库中的数据更新本地模型并发出更改事件。视图将通过调用getTasks()
方法并更新状态来响应。
这很有效,但感觉不是很反动。我需要一个单独的方法来公开查找所有任务,例如,在meteor提供的反应视图的文档中,它们有自己的特殊功能,包装组件并在数据更改时更新组件的支柱
export default createContainer(() => {
Meteor.subscribe('tasks');
return {
tasks: Tasks.find({}, { sort: { createdAt: -1 } }).fetch(),
incompleteCount: Tasks.find({ checked: { $ne: true } }).count()
})
这似乎是流星的设计方式。视图对数据更改做出反应并在所有平台上实时更新,我只是不确定我是否实现了通量模式是保持该设计真实性的最佳方式,或者我是否应该努力保持真实性那个设计。
作为免责声明,我对磁通模式和Meteor框架仍然是一个新手。