Thanks for the test. That’s what I guessed was happening, yeah… cleared first, processed, then appended. Most likely none of this will change, as it’s kinda core and changing it could blow things up. But, for science…

I guess first the expectation/spec should be defined of what “should” happen. This is (or was) my expectation:

1. Square brackets define a function (the code within the square brackets) and a spot in the HTML.
2. The function is run.
3. Its result replaces the spot where the square bracket text used to be.
4. Update() will do the same process: run the function, and the same spot is replaced with the new result.

(There are of course other ways of defining things. I just don’t think it’s actually defined by the dev anywhere, but more cludged together–as is the style of perchance. 😉)

So the tricky part here is, in step 3, what happens if the spot no longer exists by the time the function is processed the first time? My expectation:

• The spot would not be replaced.
• And if the square brackets don’t exist by the time square block processing gets to it the first time, it would not be processed at all and could not be updated–something like that.

If you rewrite the innerHTML/innerText, the old text nodes are disconnected from the DOM. So then you can check if the old ones still have a parent (or the same parent perhaps). If not, don’t do the replace step.

Similarly for an update, you could keep a reference to each top-level element created by the code block. Then in the replace step remove as many of them as are still within that same parent, and add the new stuff in at that point–“replacing” it with the result.

I would also expect that if the entire contents of an element is square brackets, the entire contents would be lost on an update. So that would be an easier edge case to process in any case.

I just updated with a test5, which has a more complex case. The result is pretty wild! 😂 I don’t know how anyone would’ve guessed that is the expected behaviour; seems pretty complex. 🫠