Example: https://perchance.org/3o1sbun1w3#edit

Seems like what’s returned at the end of the square brackets is somehow added, instead of setting what replaces the square brackets. Potentially, it’s cleared, then the square brackets are processed, then the result of the square brackets is added?

  • @perchanceMEnglish
    1•7 days ago

    Hmm, it’s hard to say whether this should be expected behavior. I think messing with the innerHTML/innerText/textContent of a ‘templated’ HTML node is currently undefined/unspecified behavior unless someone has strong opinions that they can defend here.

    Are there use cases that you can point to, which point to a desirable behavior here? Or anything that points to clearly-wrong behavior?

    In any case, I’ve added it to https://perchance.org/known-bugs as something to think about

    • TAPgilesOPEnglish
      1•7 days ago

      In another comment on this post I talked about my own expectations.

      And that example I linked to in the post has some very weird behaviour being demonstrated.

  • VioneTMEnglish
    1•10 days ago

    I think it is because, the action/code of test.innerText = "text", returns a string/text would output it from the square brackets. Just tested using console.log(test.innerText = "text"), and on the console it outputted a string.

    EDIT: Also, accessing element.innerText or .innerHTML would output a string, so it would also be displayed using [element.innerText]
    EDIT2: I think yes, evaluating the square brackets also takes priority before displaying the result of the square bracket. Which is why it is doubling.

    • TAPgilesOPEnglish
      1•10 days ago

      I know the assignment would return the string also. But then you’d think it would be the same as:

      var result_from_square = (test.innerText = "text");
elem.innerHTML = result_from_square;

      Which should be doing the same exact thing twice. But it’s not, hence the post.

      There are other oddities around this as well. Adding Text nodes to the element, and then updating the element which should wipe it… leaves those text nodes there. Stuff like that. It’s all likely from the specifics of how it updates and runs square code. And most of the time won’t matter. But when it does matter, it’s confusing, and needs more and more specialised knowledge about the innards of perchance to even understand what’s going on and how to fix it.

      • VioneTMEnglish
        1•9 days ago

        Going through the debugger in the code, the process seems like this.

        1. It takes the ‘text’ nodes on the element - since the Perchance syntax is there, e.g. <p id="out">test [out.innerText = 'new']</p>, where the text node is test [out.innerText = 'new'], then the element out would be left like <p id="out"></p>.
        2. It then evalutes the square brackets [out.innerText = 'new'], which would set the value of the out to <p id="out">new</p>.
        3. After that, since [out.innerText = 'new'] returns a value, which is the string new, it would then circle back to the original text node which is test [out.innerText = 'new'] and replace the square bracket with the evaluated text like so test new.
        4. It would then append the evaluated text node to its parent element which would result to <p id="out">testtest new</p>.

        Maybe on the process between adding/inserting the new text node there would be a check of the nodes again? Though not sure how to check if the parent node’s text node content is ‘replaced’ or just ‘appended’ to.

        The setup that I had to check the code is this. The Dev Tools should be open for the ‘debugger’ to work, and that keyword doesn’t work inside the square brackets, hence the use of a function.

        <p id="out">test [test()]</p>
<script>
  function test() {
    debugger
    return out.innerText = 'new'
  }
</script>

        If you had the square bracket call outside the element it is editing, it works fine.

        <p id="out">test [out.innerText = 'new']</p>
[out.innerText = 'new']

        @[email protected] - pinging dev for insights.

        • TAPgilesOPEnglish
          1•9 days ago

          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. 🫠