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?”
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.
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.)
These are two instances of the same grid class and, as you can test by sorting, each has its own independent store instance.
Note: I wanted to test how Ext 5 and Cmd 5 behave when I put everything in one file. In real life you would place model and view in separate files where they normally belong.