I’m not sure if this is a bug or what, but there’s something unexpected going on.

I’ve set up a test for you to see here: https://perchance.org/sxvghvl53i#edit

I’ve got an $output that creates HTML, which contains the code [a.html], but escaped so that it’s not processed. So: \[a.html\].

This is then injected into the page, and actually processed correctly, replacing the contents with the a.html value. But then calling update() on that element either does nothing or throws an error of one kind or another.

It says that a_elem is undefined, when it should have already been injected into the page.

Honestly, I’ve been fiddling with this test for a while now and I can’t quite pin down exactly how it works or what this works and that doesn’t or what order things are being processed in… But some sort of shenanigans is going on.

If this is all working as expected, I’d love to learn how it works. But if not, consider this a bug report 😅

  • VioneTMEnglish
    1•3 months ago

    The problem with it is that (I think, I’m not sure), while it reads from left to right and top to bottom, the function add() has been called before even the [a] is resolved. You can fix that by enclosing it in a setTimeout to wait for the element to be loaded first before adding the new one.

      add(msg) =>
    setTimeout(() => {
      a.html+=msg;
      update(a_elem);
      return "";
    }, 1);
    return '';

    Another problem is when you use <span id="a_elem">\[a.html\]</span> for the [a], upon loading it on the HTML, the \[a.html\] is gone. It would only have the ‘A’, so even if you update it, you aren’t updating anything (essentially saying that [a.html] has been evaluated and you are only updating ‘A’).

    • @wthit56OPEnglish
      1•3 months ago

      Why has add() been called first? It comes after [a], so it should be resolved after a. Right?

      • VioneTMEnglish
        1•3 months ago

        What I mean is after [a] has been called, the [a.add(...)] is called immediately after, without waiting for [a] to finish placing the element, in which the add(...) cannot call the a_elem since it hasn’t loaded yet.

        • @wthit56OPEnglish
          1•3 months ago

          Interesting… I don’t know why [a] would be async like that. Or if all [brackets] are processed later, processing them in order seems to be the easiest way anyway. Like… it’s not a big deal to put something in the DOM, it doesn’t need any delay, it can all be immediate.

          I think you’re right, that’s how it works, for whatever reason. This behaviour is just quite intuitive even for web devs like me–I’d avoid it at all costs in my own projects! 😂

          @perchance Any word on why it works like this, behind the scenes? I’m curious to understand it better.

    • @wthit56OPEnglish
      1•3 months ago

      Could you explain why the escaped html works when the preview loads then? Because it seems to properly pick it up and evaluate it–just as if it were directly in the HTML pane unescaped. It just stops being properly picked up and evaluated after that.

      And if I don’t escape the [brackets], it would come out as plain text with just A anyway right? And still would not be updated correctly.

      • VioneTMEnglish
        1•3 months ago

        Using the $output seems to evaluate the expression first before displaying it on the HTML.

        You can try, instead of using $output, to use a variable like b, then use it like [a.b] or remove it from the list and just a separate variable [b] and it would not display the evaluated item, but escaped brackets.

        If you were to use $output, you can try to double escape it like \\\[a.html\\\] and it should output the same as using the b method.