Blockly: Proposal: Wait to Set Field Value Until SourceBlock is Set

Created on 24 Jun 2019  ·  5Comments  ·  Source: google/blockly

Problem statement


Setting the field value before the source block has been provided causes a few problems:
1) Class validators are not allowed to access the source block or workspace.
2) Local validators don't run on the field's constructed value.
3) initModel exists when its functionality could (and should) be handled by doValueUpdate_.

Proposed solution

I think all of the above could be solved in a backwards compatible way simply by caching the field's constructed value, and not setting it until the source block has been provided.

  • Class validators could then be assured that the source block and workspace exist.
  • Local validators would be able to run on the constructed value and still access the sourceblock and workspace without worry.
  • initModel functionality could be easily moved to doValueUpdate_, simplifying the field lifecycle.

Additional Information


N/A

fields feature request question

All 5 comments

I need to look into this more and possibly rework this proposal.

So initModel is useful in this case:

  • A field's default value cannot be set without access to the block/workspace.
  • You want to create the field on a headless workspace.
  • The field does not have a value contained in XML.

But I can't see why the third point would ever be true, since when you serialize a workspace all fields serialize their values, so I'm not sure that it's important to support this use case.

Besides possibly keeping the initModel function the proposal stands.

The third point is often true for toolbox XML, which tends to leave off the field values and let it use the default to make the code more readable.

We attempted a version of this in the configure PR: https://github.com/google/blockly/pull/2915. Although I think it's possible to go down that route, there are a number of ways fields can be initialized today, both in rendered and headless mode that we'd need to dive deep into each of those ways to make sure we don't break any assumptions about the fields state at the time of initialization.

Closing, I don't think the benefits out-weight the costs for this one.

Was this page helpful?
0 / 5 - 0 ratings