reflux / refluxjs

A simple library for uni-directional dataflow application architecture with React extensions inspired by Flux
BSD 3-Clause "New" or "Revised" License
5.36k stars 330 forks source link

how to know if anyone is subscribed/listening to my store? #482

Closed UXDart closed 8 years ago

UXDart commented 8 years ago

Hello I'm using store.listen(method), and Reflux.createStore(...), how can I know if or how many if possible are listening to "this" store (so I need to know that inside a store custom methods)?

or is there any event to know of a subscribe and unsubscribe to my store? (that would be even better)

TIA

BryanGrezeszak commented 8 years ago

If your store needs to be aware of who is listening in order to perform its functionality then you have an XY problem.

That's simply not the direction of the 1-way data flow. If the store is dependent on who is listening then that means every listener is dependent on every other listener too, because each one changes the way the store functions in its own way simply from listening or not...which is exactly the sort of interwoven complex dependency a library like this exists to remove.

Stores should only be aware of components via the actions they emit. So you may need to rethink your approach.

UXDart commented 8 years ago

I agree... the use case is this: I have a page that uses a store... the store has a feed of posts... now I want the store to update the feed every one minute, if there are changes it triggers an update, but only if someone is using it. if not it will update for no one. should I add the action of the one minute refresh in each page for each store? TIA

BryanGrezeszak commented 8 years ago

If I understand you correctly: The issue is that it involves an API request and you don't want the store to do that request if nothing is going to use the result of it anyway. Is that right?

There's nothing wrong with the idea of tracking when there's need to update from the API or not...just don't do it that way. Do something like create actions that components will dispatch when they start needing tracking, and when they stop. Then track how many are in need at a given moment that way. Update if there's one or more, don't if there's zero. That way you have a real and intended part of the application state determining when the store is acting a certain way and when it isn't.

Otherwise you're creating a situation where a seemingly innocuous thing becomes a feature breaking bug. What If I come in later and add something that listens to stores as part of tracking user interaction? Guess what...I broke your store just by listening to it! Never build an app where it's THAT easy to break. And especially don't make a habit of it and end up with one of those programs that are impossible to work with because no matter what you do it ends up breaking something completely unrelated that depended on some obscure fact like making sure nobody listens to a certain store

UXDart commented 8 years ago

Thanks, that is what I'm doing atm (increment/decrement to know how many needs the refresh feature). I will leave it that way. Thx!