Circular Dependencies between Stores

[facebook]

Circular Dependencies between Stores

[justin808]

Here's my attempt to resolve this.

#48

[fisherwebdev]

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.

[fisherwebdev]

The idea for a shared object for dispatcher tokens seemed interesting, but I don't think it will work -- you would still need to get the last message from the MessageStore, which would necessitate a require.

[gsklee]

Is there any concrete advice now on how to handle the circular dependency problem between stores?

[tobice]

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:

• StateStore that contains the current game state, i. e. playing, paused, over and responds to actions like PAUSE or RESUME.
• CharacterStore that contains the current position of the game character (i. e. coordinates) and responds to actions like MOVE_LEFT, MOVE_RIGHT etc.

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)

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

[kyldvs]

@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.

// Not inline
const gameStatus = StatusStore.get();

// Inline
const gameStatus = require('StatusStore').get();

// Or move it to a function
function getStatusStore() {
  return require('StatusStore'); // or however else you get the reference
}
const gameStatus = getStatusStore().get();

---

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.