Comments (12)
Open license; you're free to do whatever you want.
Personally, I'm finding the trick with React & Flux is how to model some particular state change such that you don't find yourself trying/needing/wanting to issue dispatches from inside component life cycle functions or otherwise circumvent the dispatch flow as you are doing here.
from flux.
@sterpe I'm not dispatching from the component. This code is an action from flux. So instead of making a global dispatch that stores listen to and do stuff, I do the stuff needed in the action and in this particular order, which is easier to read IMO. No need for waitFor. I'm only asking what are the benefits of using a strict flux architecture vs my version.
- Flux flow: view->action->dispatcher->stores->dispatch->views-updated
- My flow: view->action->stores->dispatch->views-updated
I'm only skipping the dispatcher from the view.
from flux.
stores->dispatch->views-updated
eh, stores should be event emitters and that should be their mechanism to notify the views listening to them of updated, I guess that was typo?
from flux.
Yes, isn't that what I've said?
- Store emits (dispatches) the change;
- Views which listened to store update;
Store->dispatches->then the views update
from flux.
Sorry I read it as another action being dispatched, which seemed wrong.
from flux.
@totty90, As the application grows, say you add ten more stores for planetary defense, ship drive efficiency, etc you will have to modify each "action" fn to call & update the particular store. Compare with using the dispatcher where you would only declare what actions this store updates against within the store itself.
from flux.
Please take questions about variations on Flux or quasi-Flux experiments to the React Google Group, rather than this repo.
from flux.
@fisherwebdev Ok.
@sterpe But in your case with 100 stores and 100 actions. If your flow is distributed between 100 of stores, how can you read the code? You will have to jump from store to store to see the sequence, then you should also check all the waitFor preconditions. In your case, where you have the code in the store you will have stores which handles lets say 100 actions (not real, just for the example). Which one is easier to debug/check the dependencies and check the flow of the program?
Continue here: https://groups.google.com/forum/#!topic/reactjs/krY5aiMk540
from flux.
If your flow is distributed between 100 of stores, how can you read the code? You will have to jump from store to store to see the sequence, then you should also check all the waitFor preconditions.
No one sits down to just read an entire codebase, normally you want to focus on one concern and with stores that one concern should be in one place.
(not real, just for the example)
Exactly. Not real at all, what you are describing is a God object not a well factored store.
from flux.
@briandipalma even with my game example above, putting everything in each store is harder to maintain.
No one sits down to just read an entire codebase, normally you want to focus on one concern and with stores that one concern should be in one place.
Normally you don't need to read it all, but for example I would like to know what exactly happens when I click on a button. If you have unexpected behaviour you have to check all the stores for that particular action. If you have an action you read it all there. I can't see any use case / making my life easier about storing that logic in each store. But this is me. Have you developed any app with pure flux? Show me your code or part of it.
from flux.
Following that logic you should put all your code in one file so you don't have to look at any other files.
If you have unexpected behaviour you have to check all the stores for that particular action.
Personally I wouldn't do it that way, I'd open up the view and then the store/stores that provide data to the view that appears incorrect and debug in that order. What you are doing in your pattern is making the stores mutable from outside. This negates one of the advantages of flux, as long as you are dealing with manageable interactions this seems fine but it's more difficult to scale with increasing complexity.
By the way I believe the action is simply an object literal with a type property, the action creator is the module/class with the API on it.
I think it's quite handy to decouple the action creator and the store processing the action as it allows users of your flux component to easy add their own stores without having to modify the action creator code. All they do is register to the dispatcher, while in your pattern they would have to register to the dispatcher and modify the action creator code. Also if you wanted to see what action a store responds to you would have to look at all action creators and see if they call the store. In essence the reverse of your "what stores are notified by what action" problem.
from flux.
Following that logic you should put all your code in one file so you don't have to look at any other files.
This is not the same logic. I've said to only keep in an action the whole flow. So when I look at an action I can see everything it does. Is not the same as putting all the code in the same file, as you can think.
All they do is register to the dispatcher, while in your pattern they would have to register to the dispatcher and modify the action creator code.
No, just change the action creator code.
Also if you wanted to see what action a store responds to you would have to look at all action creators and see if they call the store. In essence the reverse of your "what stores are notified by what action" problem.
That's also true. So the final question is: do you want to see what an action does or what a store responds to. Normally you want to know the flow other times you want to see what changes a store. Both can't be done together. For me is more useful to see what happens when an something triggers an action than knowing what changes a store.
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.