Access the block's height and width excluding child blocks

[BeksOmega]

Check for duplicates

• I have searched for similar issues before opening a new one.

Problem

code.org wants to create a flyout field that is sized to the existing size of the block, so it takes up an entire input row. But currently there is no way to access with width of the block excluding children, so this isn't possible.

Request

Add a way to access the block's height and width excluding child blocks. We cannot use getHeightWidth because that is already taken, but maybe we can use getHeightWidthWithoutChildren.

Alternatives considered

N/A

Additional context

N/A

[maribethb]

This is kind of weird because the width of the block depends on the width of its fields. But a field wants to know the width of a block if it weren't there? So it's possible that there is some custom code needed in their renderer that doesn't belong in core because the core method wouldn't be able to calculate the width of the block in the middle of block rendering, if that makes sense.

[BeksOmega]

I think how we would want this to work is that the field says it has a width of 0 (i.e. don't care about this field when the renderer is measuring the block) and then after the block has finished rendering, the field resizes itself to fill up the available space on the fully rendered block.

But the field can't fill up the available space unless it knows the width of the block sans-children.

The width sans-children could be calculated by a custom renderer, but I don't know where the custom renderer could store the calculated value in such a way that the field could access it.

[BeksOmega]

So Mike ended up resizing this based on the width of one of the path elements. In the general case this does not work, because the flyout will be sizing to match the block based on outdated data. This is because our render flow goes like:

1. Get the sizes of all of the elements (including fields)
2. Calculate the size and shape of the block based on that.
3. Update the path elements.

So in general, if you update the size of fields based on the path elements, you're going to be working off of old/invalid data.

However, on load (somewhere) an additional render is being triggered, so the field has a chance to resize to match the block. This is enough for code.org to be unblocked.

So this issue is actually broader than I first assumed. The issue is we don't have a good way for fields to resize to match the size of a block. (This is an issue we may or may not want to solve)

If we do want to solve it, we could trigger an additional render on all fields after the block has been rendered, so that the fields can resize themselves. But if the fields resize themselves outside the bounds of the block, that would be a problem.

And we still have the original problem, of not being able to access the size of a block without the size of the children included.

[BeksOmega]

Additional request: https://groups.google.com/g/blockly/c/qBqn-N252dY/m/nsDGcn5jAQAJ

The docs on the width field also indicate it won't include children.

[mark-friedman]

Additional request: https://groups.google.com/g/blockly/c/qBqn-N252dY/m/nsDGcn5jAQAJ

The docs on the width field also indicate it won't include children.

The doc says that it will include children which are value blocks, which is, I believe, what this latest request is asking for. I think that the fix is to record the value of this.info_.width on the block, in addition to this.info_.widthWithChildren, in the Drawer.recordSizeOnBlock_ method in drawer.ts.