Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Circular Dependencies between Stores #28
The current flux-chat example has a bug that means it doesn't update the lastMessage object in the ThreadStore. Trying to reconcile this by waiting for the MessageStore to complete (and then request the message list from the store) creates a circular dependency between MessageStore and ThreadStore.
I've ended up fixing this by doing the following:
I'm curious if modifying the payload is the appropriate way of fixing this kind of issue. It seems like a viable option given that the waitFor guarantees that the message callback has completed, but does require a different way of storing dispatch tokens.
The other solution I had was to simply require MessageStore inside the ThreadStore callback instead of at the top of the file, but this felt a bit hacky.
Is mutating the payload considered an acceptable way of resolving this between stores, or is there a more 'Fluxy' way of doing things?
Well, I think all we need on on lastMessage is the date and whether or not it has been read. CREATE_MESSAGE could contain the date and anything created is obviously already read. This could be one way to go -- let the ThreadStore respond to CREATE_MESSAGE by creating a lastMessage object and mark it as read. CREATE_MESSAGE should be modified to contain the date. Not sure we need any other data in the lastMessage object.
Hi, this issue is rather old but I'd also like to hear more on this. There are problems that contain circular dependencies stemming directly from their nature. There is no way around. How should we face them?
To give an example we can talk about, let's consider a game with two stores:
When the game is paused, the CharacterStore shouldn't respond to any actions so it depends on the StateStore. But when the MOVE_LEFT action is dispatched and the game character falls into a trap (which is handled by the CharacterStore), the game state should change to over, so clearly the StateStore depends on the CharacterStore here.
The order in which the actions are handled is not a problem here. So I could solve this by instantiating both stores and exchanging references between them so they could both arbitrarily read from each other (something like the shared object for the dispatcher tokens, except it wouldn't be just the tokens, it would be the actual instances of stores). That would solve it... but is it right?
The other way would be to merge those stores into one. That would be logical. However, in a more complex example (with more stores representing the game situation) it could mean collapsing a huge app into a single store. There would not be much of Flux left.
Is there any strong opinion on this? Possibly my whole thinking is wrong. It's probably naive to expect Flux to work in every situation.
(I posted similar question on StackOverflow as well)
@tobice sorry for the slow reply. I think what we typically do in this situation is allow both stores to reference each other in a circular manner, generally via an inline require.
Going to close this out as there seems to have been sufficient discussion and the chat example was also removed. If there are still specific questions or action items feel free to reopen or file a different issue.