Knockout-Contrib / Knockout-Contrib/KoGrid

$userViewModel 's non-obvious behavior notice

Open
#210 1 comment 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.