javascript - Flux architecture misunderstanding in example chat app -

javascript - Flux architecture misunderstanding in example chat app -

i'm trying understand flux illustration chat app. authors mention unidirectional info flow:

however, in illustration app there dependencies between action creators (chatmesssageactioncreator) , stores (messagestore), , between stores (messagestore, threadstore) , web api utils (chatmessageutils), seems against unidirectional info flow rule:

is recommended follow given example, or should 1 design improve pattern?

update

i figured out chatmessageutils doesn't belong web api utils, 2 arrows store shouldn't point there, hence maybe they're okay. connection between actioncreators , store seems still strange.

the illustration bit forced, , created purpose of trying show how waitfor() works. webapi aspect of illustration pretty half-baked , should revised.

however, though messagestore.getcreatedmessagedata(text) passes value store, it's still getter. it's not setting info on store. it's beingness used utility method, , revision (pull request?) move method utils module.

to improve upon illustration real world, might couple things:

call webapiutils store, instead of actioncreators. fine long response calls actioncreator, , not handled setting new info straight on store. of import thing new info originate action. matters more how info enters scheme how info exits system.

alternatively, might want have separate client-side vs. server-side ids messages. there might few advantages of this, managing optimistic renderings. in case, might want generate client-side id in utils module, , pass id along text both dispatched action , webapiutils.

all said, yes illustration needs revision.

javascript facebook reactjs-flux