admin 管理员组

文章数量: 1086019

I'm trying to understand the Flux example chat app. The authors mention this unidirectional data flow:

However, in the example app there are dependencies between Action Creators (ChatMesssageActionCreator) and Stores (MessageStore), and between Stores (MessageStore, ThreadStore) and Web API Utils (ChatMessageUtils), which seems to be against the unidirectional data flow rule:

Is it remended to follow the given example, or should one design a better pattern?

Update

I figured out that the ChatMessageUtils doesn't belong to Web API Utils, so the two arrows from store shouldn't point there, therefore maybe they're okay. However the connection between the ActionCreators and the Store seems still strange.

I'm trying to understand the Flux example chat app. The authors mention this unidirectional data flow:

However, in the example app there are dependencies between Action Creators (ChatMesssageActionCreator) and Stores (MessageStore), and between Stores (MessageStore, ThreadStore) and Web API Utils (ChatMessageUtils), which seems to be against the unidirectional data flow rule:

Is it remended to follow the given example, or should one design a better pattern?

Update

I figured out that the ChatMessageUtils doesn't belong to Web API Utils, so the two arrows from store shouldn't point there, therefore maybe they're okay. However the connection between the ActionCreators and the Store seems still strange.

  • javascript
  • facebook
  • reactjs-flux
Share Improve this question edited Oct 10, 2014 at 13:07 Csati asked Oct 10, 2014 at 9:16 CsatiCsati 1,2711 gold badge15 silver badges29 bronze badges
Add a ment  | 

1 Answer 1

Reset to default 10

The example is a bit forced, and it was created with the purpose of trying to show how waitFor() works. The WebAPI aspect of the example is pretty half-baked and really should be revised.

However, even though MessageStore.getCreatedMessageData(text) passes a value to the store, it's still a getter. It's not setting data on the store. It's really being used as a utility method, and a good revision (pull request?) would be to move that method to a Utils module.

To improve upon the example for the real world, you might do a couple things:

  • Call the WebAPIUtils from the store, instead of from the ActionCreators. This is fine as long as the response calls another ActionCreator, and is not handled by setting new data directly on the store. The important thing is for new data to originate with an action. It matters more how data enters the system than how data exits the system.

  • Alternatively, you might want to have separate client-side vs. server-side IDs for the messages. There might be few advantages of this, like managing optimistic renderings. In that case, you might want to generate a client-side id in a Utils module, and pass that id along with the text to both the dispatched action and the WebAPIUtils.

All that said, yes the example needs revision.

本文标签： javascriptFlux architecture misunderstanding in example chat appStack Overflow

版权声明：本文标题：javascript - Flux architecture misunderstanding in example chat app - Stack Overflow 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://roclinux.cn/p/1744055328a2525745.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。