Frontmatter
| id | 3603 |
| title | Neo.data.Store needs a `fields:[]` config |
| state | Closed |
| labels | enhancement |
| assignees | [] |
| createdAt | Dec 15, 2022, 6:08 PM |
| updatedAt | Dec 15, 2022, 10:28 PM |
| githubUrl | https://github.com/neomjs/neo/issues/3603 |
| author | maxrahder |
| commentsCount | 3 |
| parentIssue | null |
| subIssues | [] |
| subIssuesCompleted | 0 |
| subIssuesTotal | 0 |
| blockedBy | [] |
| blocking | [] |
| closedAt | Dec 15, 2022, 10:28 PM |
Neo.data.Store needs a fields:[] config

Hi @maxrahder, @Dinkh,
I just checked the code again. While a store does indeed not have a fields config, a model is defined like this inside the store class:
beforeSetModel(value, oldValue) {
oldValue?.destroy();
return ClassSystemUtil.beforeSetInstance(value, Model);
}
Meaning: we can pass a model class / module, an instance or a config object.
So, we can do the following:
class MyStore extends Store {
getConfig() {return {
//...
model: {
fields: [/*...*/]
}
}}
}
While this is a little bit more typing, it does feel a bit cleaner, since fields is supposed to be a model config.
In case we would add it on a store level, to reduce the tiny overhead, there would need to be a check if the model config is null (otherwise throw an error). Then we would need to create the model: {fields: []} and delete store.fields afterwards to ensure there is no pointless overhead (memory usage).
Is this sufficient or would you still like to see the new config?

That's more consistent and logical really. And then if needed, people can set other model configs too.

deal.
we could open a new ticket though for view model stores, in case you would like to see anonymous stores in there.
Stores have models, and Neo.data.Model has a fields:[]. But if you only needs to specify fields, which is the most common use case, then it's a chore to have to code the separate model class. Coding fields:[] as part of the store config would be a nice convenience, and would actually be better coupling for stores that have a 1..1 relationship to their view class. I.e., why code a (reusable) model class if it's only used in a single store?