Given a store like this, at runtime, the storeId
will be App.store.Entities
instead of Entities
:
Ext.define('App.store.Entities', {
extend: 'Ext.data.Store',
storeId: 'Entites',
The documentation states:
Note that when store is instatiated by Controller, the storeId will be overridden by the name of the store.
This is not only true when the store is required in the controller with
stores: ['App.store.Entities'],
but also when it is asynchroneously created with
this.getStore('App.store.Entities')
This is all expected behavior, but I don't like that fact, that this behavior forces the use of either
App.store.Entities
The problem I have is that my app grows quite large, and having all store
definitions in one store
folder is no longer an option. I'd like to refactor to have a folder structure like follows.
/app
/plugin1
/store
/Settings
/Details
/model
/view
/plugin2
/store
/Items
/Settings
/model
/view
If I could force the storeId
, I could define it like 'plugin1.Settings'
and would come up with more readable and more portable code than repeating 'App.plugin1.store.Settings'
over the place.
How could I possibly solve this issue ? Where could I go off to start ?
Actually, I do not let Ext to instantiate my stores (only in rare cases) because that prevents creating multiple instances of the same view class. I instantiate stores manually in views' initComponent
overrides.
This allows me seamless multiple instances plus I could choose storeId
if I wished to - I usually don't use storeId but I'm getting stores from views.
However, if you only need to choose storeId because of folder organization, you can use shorter names such as subfolder1.StoreName1
, etc. but the folder structure must be split inside the store
folder.
app/store/subfolder1
app/store/subfolder2