ExtJS 4 Web Application State Management

Question

I am creating an ExtJS 4 single-page web application, and coming across some issues deciding on the MVC-favoured way of defining and maintaining my application state. I am aware of the global nature of ExtJS 4's stores, and I like the idea of them, but the practicalities of them are called into question on a couple of points.

For example, I have models that could possibly need to scale into the thousands at some point, and the idea of loading all of these into the memory of the client's browser does not strike me as the best of ideas. I would have great performance concerns with trying to do this.

Additionally, my application will have windows, multiples of which that may be viewed at the same time, in addition to multiple grids on the same tab in a tab panel. These views are supposed to show a subset of the models based on their properties. If these views are tied to the same global store and its models, they will be affected by operations such as filter and will effectively be restricted to showing the same set of models, which is not what I am trying to achieve.

So my actual question is how do I go about handling this situation? I have read a similar concern on StackOverflow that called for the views to hold their own instance of the store rather than using the global instance, but I am not sure this fits the MVC pattern correctly. My current thinking is along the lines of having a controller that manages the state and holds the various instances of the stores so they are not directly tied to the views and yet they can still be accessed on event calls and by other controllers. Is this a good solution or am I missing something?

Answer 1

Well, there's a lot going on in your question. First of all, I think you are over-thinking stores a bit. Ultimately, a store is just a cache of model instances. So you can create as many instances of them that you want, depending on the requirements of your application. If you want to try to use a single store to manage the entire data set, you can certainly do that, but you'll have to be VERY aware and vigilant in keeping track of filters/sorters/etc that you apply throughout the flow of your application.

Re: the scale of your application's data, I would strongly suggest not trying to load all your model instances in at the same time (depending on the size and complexity of data, of course). Unless you actually need all possible instances available in the application at all times, I would adopt an approach that loads only what you need, depending on the scenario. If you need access to thousands of records, you can always apply remote filters to still deal with the whole data set on the server side, but only actually interact with a subset of the data on the client side.

Ultimately, I wouldn't worry so much about whether or not a particular approach "fits" the MVC pattern (which is itself a very particular flavor in Ext JS, a flavor not desired by everyone...). Yes, you want to create an approach that is extensible and manageable; however, I would argue that the requirements of your application should drive how you utilize the MVC conventions that Ext JS 4 provides, rather than allowing the MVC conventions to determine your business requirements.