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_.
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.
N/A
I need to look into this more and possibly rework this proposal.
So initModel is useful in this case:
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.