fix: switch most remaining render calls to queueRender

[BeksOmega]

The basics

• I branched from develop
• My pull request is against develop
• My code follows the style guide
• I ran npm run format and npm run lint

The details

Resolves

Was looking at #6980 and realized it would be easier to document if we just have one rendering path rather than two :P So I'm looking at trying to get rid of the old one.

Proposed Changes

Looked through all of the remaining uses of render and switched any over to queueRender that could use queueRender.

Remaining uses of render after this PR include icons (because they need to know their locations immediately) and deserialization (because it's causing forced layouts that I need to investigate).

Reason for Changes

Unification of rendering paths.

Test Coverage

Manual poking at things.

Documentation

N/A - but soon! hopefully 🤞

Additional Information

The plan for the icons is to add a function to the render management system that forces an immediate render of all queued renders.

[maribethb]

mostly questions so i understand how rendering works!

[maribethb]

Can we instead maybe add the comment icon in the afterQueuedRenders or whatever we called it? I don't actually know what I'm talking about here so feel free to ignore me if this is nonsense :p

otherwise: nit: (here and below) immediately typo

[BeksOmega]

Wrt your comment about finishQueuedRenders, that doesn't solve for this use case because the icon needs to be appended to the block before the render is triggered so the renderer can position it correctly.

But now that I'm thinking about this again, I'm going to investigate this one more time.

I was trying to solve for the use case of:

myBlock.setCommentText('yay a comment');
myBlock.getCommentIcon().setVisible(true);

I thought that for this to correctly position the bubble, the setCommentText method must:

1. Append the comment to the block.
2. Rerender the block to position the icon.
3. Tell the icon what its new position is.

So that when setVisible is called, the icon has the correct information to position the bubble.

But thinking about it again, if we use the render queueing it should look like:

1. Append the comment to the block.
2. Open the bubble at the incorrect position.
3. Rerender the block to position the icon.
4. Tell the icon what it new position is.
5. Update the position of the bubble for the new position of the icon.
6. Actually paint the frame to the screen.

This should still be correct. But it was causing some unit tests to fail, so I need to remember why that was.

[BeksOmega]

@maribethb I tried wrapping the setVisible calls so that the logic is triggered after the current render completes, but that means that external developers won't be able to access the contents of the bubble immediately (e.g. the mutator workspace).

I don't particularly like that breaking change, but on the other hand I don't really like external developers messing with the contents of the bubble anyway? So wanted to confirm before I go fix the 40 remaining tests :P