Closed shirakaba closed 3 years ago
In fact it happens also in other situations:
{#each ... as ...} ... {/each}
inside a {#if...} ... {/if} works correctly for the first update. But then if the variable tracked by the
{#if}changes, only the first élément of the
{#each}is inserted. The other ones fail with a
addChild() called on an element that doesn't implement nodeOps.insert() [ 'view' ]` in the console.{#each ... as ...} ... {/each}
works (even when the tracked variable is update) but still throws addChild() called on an element that doesn't implement nodeOps.remove() [ undefined ]
in the console.
This makes {#if} almost unusable 😞 .I've found the root cause of this (which would affect both #if
and #each
equally), but need to spend some more time on it to understand the appropriate way to fix it. It looks like my implementation for addChild()
is incomplete in some way. I'll have to compare with Svelte Native and figure out how to implement this missing case.
@shirakaba looks like this is the same issue I was encountering when I created that example svelte-nodegui app. (https://github.com/nodegui/examples/pull/38) the nodes weren't updating inside an {#if}
block.
Hopefully fixed with the changes I've made in v0.0.4! I rewrote a large amount of the DOM handling from the ground-up. It was handling perfectly on an #await
block wrapped by an #if
block. I haven't tried with #each
blocks yet, but we can reopen this issue if we find it still affects those.
Found in https://github.com/nodegui/svelte-nodegui/issues/40#issuecomment-803454533:
{#await}...{/await}
block with an{#if dataPromise}
, the enclosed text elements fail to update, with reasons relating to the next point.addChild() called on an element that doesn't implement nodeOps.remove() [ undefined ]
. This is something to do with updating the child text nodes passed into the<text>
element. That's a bug with the text-updating logic, though somehow we get away with it in this example. I'll track it.