Comments (7)
Here's my attempt to resolve this.
from flux.
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.
from flux.
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.
from flux.
Is there any concrete advice now on how to handle the circular dependency problem between stores?
from flux.
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)
from flux.
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.
from flux.
@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.
from flux.
Related Issues (20)
- Cannot dispatch in the middle of a dispatch. HOT 1
- New Flux store instance created upon second component referencing store HOT 7
- Flux Utils + Hooks HOT 6
- TypeError: Class constructor App cannot be invoked without 'new' HOT 1
- Using version of fbjs that depends on unsupported core-js module HOT 2
- Please update the following components: FluxContainer(containerClass) React 16.10.2 HOT 5
- how do we differ from Architecture and pattern? HOT 1
- Is this code a good way to update react component from dispatch in OOP class object? HOT 2
- Flux container breaks class methods defined with class properties syntax HOT 1
- Container create context issues after Babel 7.9.x update. HOT 5
- CVE-2020-15168 found in [email protected] HOT 13
- CVE-2020-7733 vulnerability by linking to an older fbjs version HOT 2
- Is fbemitter project discontinued? Is flux? HOT 1
- Add React 17 support
- NPM reports flux vulnerabilities HOT 3
- CVE-2021-27292: ua-parser-js needs to upgrade to 0.7.24 HOT 4
- mock flux store - react test HOT 2
- Will there be a Chinese version? HOT 1
- Video goes off screen and does not fit neatly HOT 1
- Add react-18 as peer dependency. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from flux.