Hanfei Sun
Hanfei Sun

Reputation: 47061

In Flux architecture, will a Global Dispatcher be harmful?

In Facebook Flux architecture, as I understand, there should be only one Dispatcher.

It is reasonable to have a global dispatcher which might be similar to a event bus. However, I was wondering whether it is bad to have a single and global Dispatcher.

For example, let's say I already develop a few components and my Dispatcher. Now I want to import a third-party component library, the dispatcher from the third-party can not be directly imported because there should be only one Dispatcher (and I already developed my own Dispatcher)

One solution is that the third-party can attach some behaviour to the Global Dispatcher. However, that may also be harmful. Because the event name they used may conflict with mine. For example, they use the same event name with mine, and I may trigger their events incidentally.

Does anyone have ideas about this? Thanks!

Upvotes: 0

Views: 119

Answers (1)

Michelle Tilley
Michelle Tilley

Reputation: 159105

There should be a single dispatcher per flux application — said another way, each logical set of stores, actions, and related components should have a single dispatcher.

If you use some other library, it could be managed by a flux or flux-like system under the hood, and in that case it would use its own dispatcher. However, it should surface a public API that communicates through props and callbacks, even if it uses a flux or flux-like implementation under the hood; the flux internals should not be exposed.

In most cases, I don't think it makes sense to have a library that adds specific functionality (e.g., specific actions, stores, etc.) to your own flux setup, for several reasons. However, in a theoretical case where this did happen to make sense, it should probably "plug-in" behavior to the existing system, as you mentioned, ideally namespacing things like actions.

Upvotes: 1

Related Questions