blocks|key|4490341|text|Flux作为一种设计模式是建立在所有数据都驻留在“存储”中的思想之上的。每个存储都保存给定信息域的数据。举个例子:在Flux中，所有注释都会驻留在一个CommentStore中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4490342|当存储中的数据发生变化时，它应该发出一个事件，并且构建在这个“信息域”之上的所有组件都应该重新呈现和显示新的域数据。|4490343|我发现，当存储发出多个事件类型时，组件更有可能没有侦听特定的事件，因此当域数据改变时不会重新呈现自己。|4490344|这打破了整个流量模式，并且很容易在组件与存储信息不同步的地方很难找到bug。|4490345|相反，我建议你根据“迪米特定律”来设计你的组件--每个组件应该只知道它需要知道的东西。|4490346|因此，您应该创建一个监听单个商店事件的commentListComponent，而不是监听一个事件的组件"commentList已更新“。因此，组件会监听commentStore.on(+'change‘)+--我通常会让所有的商店都发出一个’change‘事件。当存储发出时，您应该在commenListComponent中重新呈现数据以反映存储。如果你使用React，这就是你使用setState的地方。|4490347|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>
++++}
})|code-block|syntax|javascript|4490348|这使得数据流变得简单得多，并避免了难以发现错误。|4490349|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|Z|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|10|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

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.

<pre><code>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 &lt;div&gt;{comments}&lt;/div&gt;
 }
})
</code></pre>

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

blocks|key|4489400|text|我的用例迫使我使用不同的事件。我有一个地图组件，它显示了许多复杂的对象，刷新每个对象将非常昂贵。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4489401|EventEmitter2实现了多级和通配符事件。它允许我监听"change“事件，或者更具体地说是"change.add”"change.remove“……|offset|length|4489402|this.emit("change.add");|code-block|syntax|javascript|4489403|可以通过以下方式进行监听|4489404|myStore.on('change.*',+callback);
myStore.on('change.add',+callback);|4489405|通过这种方式，我的许多组件可以简单地侦听"change.*“事件。需要优化的更复杂的组件可以监听特定的事件。|4489406|两全其美|4489407|PS:别忘了启用通配符。请参阅文档|4489408|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/asyncly/EventEmitter2^0|0|0|D|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@$D|14|E|15|1|16]]|A|$]]|$1|F|3|G|5|H|7|17|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|18|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|19|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1C|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]]]

My use-case force me to use distinct events. I have a map component that displays many complex objects and it would be very expensive to refresh each.
<a href="https://github.com/asyncly/EventEmitter2" rel="nofollow noreferrer" title="EventEmitter2">EventEmitter2</a> implements multi-leveling and wildcard events. It allows me to listen &quot;change&quot; events, or more specifically sub-level events &quot;change.add&quot; &quot;change.remove&quot; ...
<pre><code>this.emit(&quot;change.add&quot;);
</code></pre>
can be listening by
<pre><code>myStore.on('change.*', callback);
myStore.on('change.add', callback);
</code></pre>
In this way, many of my components can simply listen to the &quot;change.*&quot; event. And more complex components who needs optimization can listen specific events.
The best of both worlds
PS: don't forget to enable wildcards. See documentation

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:

<pre><code>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
});
</code></pre>

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

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

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

几乎所有我找到的有关flux的教程都只在每个存储(emitChange)中发出一个事件。我真的不知道这是故意的，还是仅仅是教程简单性的结果。我尝试实现一个对应于CRUD体系结构的存储，我想知道为每个CRUD方法发出不同的事件是否是一个好的设计决策。我的一个商店的相关部分如下所示：var UserStore = _.ex...

问当一个React Flux存储发出多种事件时，这是一个好的设计吗？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问当一个React Flux存储发出多种事件时，这是一个好的设计吗？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问当一个React Flux存储发出多种事件时，这是一个好的设计吗？
EN