Reader: “Hey, Saki, wait a minute. You must be kidding. Grid must have a store; it is a required configuration option.”
Saki: “Yeah, I’m kidding, sure there must be a store for the grid. When I say “without” I mean without the file in store/ folder, without Ext.define and without listing the store in Application or a controller.”
Reader: “Well, but why to change what has worked? And if, then why?”
The Problem
You may have run into the problem with multiple instances of a class (grid, tree, dataview) that is backed by a store. If you put the store in store/ folder and list it in stores:[], then Ext MVC instantiates the store, registers it in StoreManager and makes it available for views to use.
Globally. One store instance with one storeId.
Hence, all instances of the view use the same global instance of the store. More often than not, this is not desired. Filtering or sorting in one grid automatically sorts all other grids of the same class. Same story when updating, adding and removing records.
We have learned how to solve it: Do not list the store in stores:[] but create a fresh instance in grid’s initComponent override. It is a good and valid solution proven to work. However, it adds the overhead of necessity to write the override and store creation code over and over.
The Solution
Now, in Ext 5, we can leverage View Model to hold the store configuration. View model, if used in a component (grid, tree, data view) is instantiated together with the component so new instance of the store is also created together with the view model instance. And the configuration is incredibly simple and straightforward reducing the lines we have to type.
(I love when I can remove something from the code, and it still works.)
Live Demo
These are two instances of the same grid class and, as you can test by sorting, each has its own independent store instance.
If you want to see the example, please purchase access here. If you have already purchased access, you might need to login.
- Ext, Angular, React, and Vue - 27. June 2019
- The Site Resurgence - 11. February 2018
- Configuring ViewModel Hierarchy - 19. June 2015
15 Responses
Hi,
it is possible to have an example of the json response?
The easiest is to open Chrome Developer tools, Network tab and watch the network traffic when you reload this page. See the image:
Hi Saki,
Thanks for this example, I was wondering where the data is coming from. Is that from the php call to the server?
Also – setdata (instance:1) is that an inbuilt method.
Yes, data comes from the server. You can see it at
proxyconfiguration that says that it isajaxproxy with url configured.setDatais an automatic setter function created by Ext for ViewModel because ViewModel has alwaysdataproperty.I like this use of viewmodel. But my problem with viewmodel is, that I want to be able to reference a proper extended store type. But I cannot find any example that allows the viewmodel to actually create a MyStore (when this is a defined type.)
You can give your store an alias, for example
alias:'store.mystore'and then you can settype:'mystore'in the viewmodel.No problem Tamas,
grids and stores, and of course viewmodels, are separate instances so there’s no problem with pagination.
Hello! Its a great sample! But what about paginators? Do you have tried to add paginators to grids which are works independently each other?
Grid (view), its viewmodel and viewcontoller are always created and destroyed together, therefore, viewcontroller should never pick events of other than its own view.
If you’re having troubles with that let me know I’ll test it and post an example.
Saki,
How does this work for the ViewController in this case? If I instantiate 2 grids like you have done here, I will also get 2 ViewControllers. How are events processed so an event from grid 2 is not picked up in grid 1?
You actually have a store, it is created lazy by specifying it in viewmodel / stores, it’s like embedding the store via xtype directly in the grid config. When Grid is initialized a regular Ext.data.Store Instance is created with your config.
In your example it’s the mix proxy-in-model and lazy-in-view-model which creates the store lazy for the grid.
Wrong Title, I think.
I have chosen the title to provoke curiosity, not that we can really have a grid without a store. Also, I explain what I mean by “without” in the 2nd article of the post.
Remote filtering and sorting is not possible on the chained stores, only on the main store.
The typical usecase of the chained store would be when you can load all records to the standard main store and then filter/sort the records independently in the chained store.
Or, when you filter the main store, e.g. by userId or role, and you want all chained store to be immediately filtered the same way. Of course, further filtering/sorting on the chained stores wouldn’t have any effect on the main store.
Finally something interesting for me :o) Are there any limitations? Like remote sorts/filtering etc? I think chained store will solve described problem with sorting / filtering in store too. So why we should do this?
Now I see that you commented on “No Store” post so I add to the answer: There are no limits in this approach. The store defined in viewModel can be standard store, chained store, whatever. So my first answer only applies to chained stores.