Connecting block to parent in domToBlockHeadless_

[moniika]

The basics

• I branched from develop
• My pull request is against develop
• My code follows the style guide

The details

Resolves

Fixes #2135

Proposed Changes

• Connects block to it's parent in domToBlockHeadless_ rather than in the parent block's instantiation (allows for parent to be connected before field tag is processed)
  • Before: Block was connected it it's parent after it was fully loaded (which caused issues with fields validators that depended on the connected state of the block)
  • After: Block is connected to parent as it is being loaded, before it's field values are loaded

Reason for Changes

• Solves issues with loading blocks with field validators that depend on the parent being connected (and accessing parent fields) from xml
• Solves issues with loading dynamic dropdowns that depend on a connected parent from xml

Test Coverage

Ran tests and tested in advanced playground with the following block:

<xml xmlns="https://developers.google.com/blockly/xml">
  <variables>
    <variable>list</variable>
  </variables>
  <block type="controls_repeat_ext">
    <value name="TIMES">
      <block type="math_number">
        <field name="NUM">123</field>
      </block>
    </value>
    <statement name="DO">
      <block type="test_dropdowns_dynamic_connect_dependant">
        <field name="OPTIONS">wcjS31{oxnJqsPUgQ+_m_type_key</field>
        <next>
          <block type="lists_getIndex">
            <mutation statement="true" at="true"></mutation>
            <field name="MODE">REMOVE</field>
            <field name="WHERE">FROM_START</field>
            <value name="VALUE">
              <block type="variables_get">
                <field name="VAR">list</field>
              </block>
            </value>
            <value name="AT">
              <block type="lists_getIndex">
                <mutation statement="false" at="true"></mutation>
                <field name="MODE">GET</field>
                <field name="WHERE">FROM_START</field>
                <value name="VALUE">
                  <block type="variables_get">
                    <field name="VAR">list</field>
                  </block>
                </value>
                <value name="AT">
                  <block type="math_number">
                    <field name="NUM">123</field>
                  </block>
                </value>
              </block>
            </value>
            <next>
              <block type="test_dropdowns_dynamic_connect_dependant">
                <field name="OPTIONS">T1_y8l67gg$DXQ=u8Q~2_type_key</field>
              </block>
            </next>
          </block>
        </next>
      </block>
    </statement>
  </block>
</xml>

Documentation

Additional Information

The generator tests were very helpful for testing this change as it caught many edge cases of xml generation.

Depends on #4571

[BeksOmega]

With the new connection checker being more flexible, I wonder about connection checks that depend on the state of a parent block's fields. Wouldn't this mess with that?

[rachel-fenichel]

Some comments.

I'm nervous about this because of backwards compatibility, but agree that making our parsing more clearly defined is a good move.

[moniika]

Rebased after merging change for parsing tags in explicit order.

[moniika]

With the new connection checker being more flexible, I wonder about connection checks that depend on the state of a parent block's fields. Wouldn't this mess with that?

I don't think this would be an issue if the connection checker depends on the parent block's fields.
The xml (#4571) is loaded in an explicit order, such that, the input/statement/value fields that create the child block are processed after the field tags are processed.

However, if the connection depends on the child block's fields, then those wont be loaded yet.
(Ex: a block with boolean field that must be true in order for it's output to be connected to parent)
(Ex: a block whose field value must match the field value of the parent in order for it to be connected)
(^ In the previous release, these cases worked only if the parent field in question was listed before the child block in xml)

Other potential new issue (introduced in #4571):

• field validator depends on connected child blocks (used to work only if the field tag was listed before the statement/value/input tag in the xml)

Other Remaining unsolved issues (not new issues):

• child field validator depends on parent's other connected statement/input/value child blocks
• field validator depends on all blocks in the workspace being loaded