Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Temporary fix for consecuent ko.mapping.fromJS calls #123

Closed

Conversation

lisandropuzzolo
Copy link

If you make consecuent calls to ko.mapping.fromJS(), in some cases the computables involved on the viewmodels are not evaluated correctly.
This behaviour is noticeable if you use Validation plugin.

I made this fix, so you can call ko.mapping.evaluateDependentObservables() between each ko.mapping.fromJS(...) call.

ko.mapping.fromJS(....); // mapping the first viewmodel
ko.mapping.evaluateDependentObservables();
ko.mapping.fromJS(....); // mapping the second viewmodel

// now both viewmodels are working correctly, specially those using validation plugin.

If you make consecuent calls to ko.mapping.fromJS(), in some cases the computables involved on the viewmodels are not evaluated correctly.
This behaviour is noticeable if you use Validation plugin.

I made this fix, so you can call ko.mapping.evaluateDependentObservables() between each ko.mapping.fromJS(...) call.


================================

ko.mapping.fromJS(....); // mapping the first viewmodel
ko.mapping.evaluateDependentObservables();
ko.mapping.fromJS(....); // mapping the second viewmodel

// now both viewmodels are working correctly, specially those using validation plugin.

================================
@lisandropuzzolo
Copy link
Author

I updated the fiddle that shows the problem, and now it run two tests:

  1. One mapping.fromJS(...) call
  2. Two consecutive mapping.fromJS(...) calls.
    http://jsfiddle.net/VCP4t/2/

As you can see, on the first test, after a setTimeout the .isValid() returns what is expected (false),
but on the second test, ir returns true, when the expected value is false.

@drdamour
Copy link

drdamour commented Jan 8, 2013

if you can make this call and evaluate the dependent observables during the current execution thread (IE: not in a function run from setTimeout or setImmediate) then why not just do it always? If the setTimeout isn't required...why have it at all? I also commented on this over @ #95

@drdamour
Copy link

drdamour commented Jan 8, 2013

i put together an alternative method of fixing this with included updated unit tests @ #126

@sagacity
Copy link
Collaborator

This is fixed in 0cfd93c thanks to drdamour's pull request

@sagacity sagacity closed this Jan 16, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants