Managing amount of client-side data

[davetayls]

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 😉

[briandipalma]

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]

So

• view calls getAllData from store
• a store would call a utility class to fetch data
• then synchronously returns [] to view as it currently has no data
• later fetch succeeds inside utility class and creates an action with returned data
• store would respond to this action and I would have thought at this point the store would cache this data and trigger a change event
• view would then respond to change and call getAllData from store and get [{},...] from returned results
• at this point I guess the store could either clear the cache of data or set a timeout to clear it later if not requested after a set period of time

does that sound like a reasonable flow?

[briandipalma]

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]

Thanks @briandipalma that's really helpful

[briandipalma]

You may find this blog interesting.