Dynamically displayed component being rendered more than once

[mbest]

codymullins:

I've been battling this one for a few weeks, and just now got confirmation that someone else was able to reproduce this and I wasn't just going crazy.

The issue arises when I am dynamically displaying a component based on some logic - in this case, I'm parsing the route and grabbing a parameter. When the component is looking at an observable to determine the name, it's being loaded twice in the getComponent call and thus my constructor is called twice. If I bind the same form with a literal string, the component only renders once.

Here's an example (it has the same issue even without the outer if binding):

<!-- WORKS, renders only once -->
<div data-bind='if: currentFormComponent() != null'>
    <div data-bind='component: {name: "my-component", params: { route: pageParams.route }}'></div>
</div>

<!-- Renders twice (currentFormComponent is an observable and is set to "my-component" as above) -->
<div data-bind='if: currentFormComponent() != null'>
    <div data-bind='component: {name: currentFormComponent, params: { route: pageParams.route }}'></div>
</div>

[mbest]

Can you put together an example in jsfiddle?

[codymullins]

Sure. I'll do it this afternoon after work.

[codymullins]

@mbest I am trying to wrap this up this morning, but it revolves around loading the component using something like require. I'm having a difficult time getting it to work in JsFiddle. Would something you can clone from github work?

[mbest]

@codymullins Yeah I'll give that a shot.

[codymullins]

@mbest I might have just found out where this is coming from. I turned off deferred updates and the problem is fixed. I think I read somewhere it was expected with deferred updates that a component could be rendered twice?

[mbest]

I don't know why it would be expected. Perhaps this is related to #2174. Could you try applying that patch and see if it makes a difference?

[codymullins]

I pulled down that branch and built it, doesn't appear to make a difference. If I call ko.tasks.runEarly() right after setting the component observable though it seems the problem is also solved. It's almost like because the component loader is taking some time to load the component, it gets attempted 2x.

[mbest]

Thanks for checking that out and the additional information. Can you share the code that sets the observable?

[codymullins]

hey @mbest I don't know why I couldn't replicate it before, but here's what I'm experiencing:

https://jsfiddle.net/11umxthr/

If you open up the console before you click the button, you'll see the console.log statement gets executed twice. if you uncomment ko.tasks.runEarly(), you'll see it does not.

[mbest]

Why are you setting currentFileComponent to one thing and then changing it right away?

[codymullins]

In this scenario there's some logic to determine which component to display based on what's in the route. I think previously I was using an if: binding and setting the currentFileComponent to null at least until one was chosen. (the example doesn't include that, I whittled it down to bare bones).

[mbest]

Your example exposes an issue that when using deferred updates a subscriber can get a notification that occurred before it subscribed to the observable. When you change the observable's value, the notification is scheduled. Afterwards the component binds using the latest value. But then it gets the notification of the same value.

As you noted, a workaround is to call ko.tasks.runEarly(). That clears the notification. Another is to schedule the update for later: ko.tasks.schedule(function() { self.currentFileComponent("main-file"); }); The component binding will first use the loading component and later update to main-file.

A possible fix for this issue is for Knockout to only call subscribers that existed when the notification was scheduled.

[mbest]

I've attached the fix here.

[codymullins]

Awesome. That was quick, you rock. I will pull this down and test it out.

[codymullins]

I can confirm this fixes the issue. I don't see any other evident side effects either.

[codymullins]

@mbest since this is merged in, are you planning the 3.4.2 release anytime soon?

[mbest]

I only just found this related SO post: http://stackoverflow.com/questions/36281676/knockout-3-4-0-deferupdates-and-reevaluation-count

[mbest]

since this is merged in, are you planning the 3.4.2 release anytime soon?

Hopefully. I just added another issue to consider for 3.4.2, plus there's a possible regression in 3.4.1 that I want to look into.

[mbest]

@codymullins 3.4.2 is now released.