Knockout-Contrib / Knockout-Contrib/KoGrid
$userViewModel 's non-obvious behavior notice
- Dominant language
- JavaScript
- Stars
- 277
- Forks
- 124
- PR merge metrics
- No merged PRs in 30d
Description
$userViewModel is using bindingContext to save viewModel, which is filling by KnockoutJS' internal logic, but that context can be changed by KnockoutJS is you are using "with":
For example, here is the page with 2 grids that have the same gridOptions, but will contain totally different $userViewModel values (for the first case it will be "clientvm", but for the second it will be "clientvm.someProperty"):
``` html
First:
Second:
```
So if you are playing some magic with $userViewModel inside your logic for this grids, you need to be sure that the same functions/properties are available on both models for "clientvm" and "clientvm.someProperty". In my case kgEditable stoped work for the second case, because "clientvm.someProperty" did not have required functions that were part of "clientvm".
I see 2 ways:
- In the ko-grid.js at 'init' function, use
``` Javascript
grid.$userViewModel = bindingContext.$root;
```
in place of
``` Javascript
grid.$userViewModel = bindingContext.$data;
```
So it will always point to root vm, but in this case root view model will be too fat for big sites.
- Leave it as is, but update documentation to explain this behavior and suggest making something like this during grid creation:
``` html
```
So grids logic can be separated from one place.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading the init function in ko-grid.js, focusing on how bindingContext.$data and bindingContext.$root determine $userViewModel, then inspect the existing documentation. Confirm with the maintainer whether the intended result is a root-view-model change or a documentation update, and document the chosen behavior with the provided with/clientvm.gridvm example.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100