facebookarchive / flux

Application Architecture for Building User Interfaces
https://facebookarchive.github.io/flux/
Other
17.38k stars 3.47k forks source link

Managing amount of client-side data #62

Closed davetayls closed 9 years ago

davetayls commented 9 years ago

How should the Stores manage the amount and persistence of data held in the browser?

When views request data from a Store, often it will need to do a server request and then the result I presume would sit in memory as application state. This is great for small amounts of data but what about when that data grows over the lifespan of an application?

At some point a clean-up of unnecessary data in memory needs to happen, but how would you go about doing this?

Hope this makes sense :wink:

briandipalma commented 9 years ago

I wouldn't use stores to handle this, I would use the utility classes to do this. They can listen to actions from the views and async request data and once they have the data they can dispatch and action that the stores can respond to. They would handle the lifecycle of subscriptions etc, keep the stores focused on domain model concerns and the utilities on data model provision.

davetayls commented 9 years ago

So

does that sound like a reasonable flow?

briandipalma commented 9 years ago

The store should not know about the utlity classes. The view calls the ActionCreator which can then call a utility which does it's async thing and when it's finished it raises an action that the stores process.

This is how the data flows down to the view from the utility. At least this is how I feel it should be done, the maintainers of flux/this repo may disagree. We're dealing with highly complex components so we need these layers others may not.

Look at this class see how it calls Utils? Not the store.

davetayls commented 9 years ago

Thanks @briandipalma that's really helpful

briandipalma commented 9 years ago

You may find this blog interesting.