Skip Navigation
7 comments

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

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

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

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

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

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

        @perchance@lemmy.world - pinging dev for insights.

  • 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

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

7 comments