Document the process of creating a custom field.

As of #1594, custom fields are now possible without modifying the core blockly code.

Audit field APIs

Improve the Field class APIs to a level we are willing to support long term.

• Use setText instead of setValue in fieldTextInput (#860).
• Extract common Field support methods into new field_util.js (#1624).
• Consistently call Field.init() from subclass .init() (or refactor to put ensure it is called in other ways).
• Split Field.init() into Field.initView() and Field.initModel() (#1010).
• Consider splitting Field view and model more completely. For instance, updateWidth() is another view specific method.
• Validation: Do we validate the text of the field, the value, or both (need separate APIs)?

Document custom field development process and concerns

Write the documentation for the following aspects of the improved API.

• Field class hierarchy, denoting where good extension points are.
• Document required Field methods and life cycle of a Field object.
• Difference between setText() vs setValue().
• Timeline and expectations between showEditor() and registering event listeners and hideChaff().
• How to attach popup editors to a field.
• Document the registration functions.

[BeksOmega]

Ok I have completed a field documentation prototype.

I tried my best to follow the Write the Docs Documentation Principles, as well as the Google Documentation Style Guide as I was writing.

I have given edit access to Abby, Andrew, Erik, Neil, and Rachel (or tried to anyway). Please tell me if anyone needs to be added or removed.

I have also shared a link with comment access on the forums, because I thought it would be a good way to get outside developers’ opinions on the changes.

[RoboErikG]

This is awesome, Beka. Just an FYI, we’re all going to be at a larger team offsite this week so reviews may be a bit slow.