The point of flux is one way data flow. Your data lives in ONE place (the "store"), and then it's fed into your views, which render it in a deterministic fashi

The point of flux is one way data flow. Your data lives in ONE place (the "store"), and then it's fed into your views, which render it in a deterministic fashion. User interaction triggers actions, which circle back around to modify the data in your stores. Data should only be modified by actions, and views should only change when your data does. There's a lot of advantages to this (in terms of performance, but much more importantly, in terms of being able to reason about your code). You could think of it as an event bus, and you might even implement it with one, but that's an implementation detail. In terms of your actual code, your store will list which actions it wishes to be respond to, your views will list which stores they want data from, and you'll have some UI elements that trigger actions. Your view doesn't "know" about events; it knows that it'll be rendered with the data it needs passed in as props, and re-rendered with the new data it needs. You're probably using PouchDB more or less as a store. If not, you probably should be, and it would be trivial to write a very lightweight wrapper around it to tie it into your existing flux implementation of choice. What flux is trying to get you to avoid is some sort of ugly ball of ad hoc AJAX calls and local component state. PouchDB is already pushing you the same direction. (Which is probably why you don't see a point.)