Wordpress seems to be moving towards client-side rendering and a more JS-driven experience, and we should build the Fields API in a way that supports such an upgrade.
We currently lack a good solution.
The problem
The Fields API is not designed to handle the rigors of cross-language rendering (or even having multiple render methods at all):
Devs can register forms as (essentially) giant arrays, but field options (like choices in WP_Fields_API_Multi_Checkbox_Control) are not sanitized or verified by default.
Any verification is done at render-time, ad-hoc by the component.
Rendering consists of echo-ing HTML.
Possible solution
One solution is to build a pluggable render system:
Update the data layer to be a public, robust, and sanitized representation that can be readily serialized
Allow render to be handled by some sort of modular "render class"
That way we could render the "New Post" form by, e.g., outputting a JSON blob of the form data and enqueuing a script that rendered the form in React.
Caveats
This system, however, lacks a sensible modularity. There are two ways to implement a custom render system, and both have flaws for plugin authors:
Walker-render: a renderer must read the data representation and output form elements for each item.
The walker must know about every form type: what if a site that wants to use CustomRenderWalker also uses CustomFormType that CustomRenderWalker doesn't know about? How can we handle this?
Field-render: all fields render themselves (current implementation).
Each field type must know about all renderers: a site that wants to do a React render must ensure that each field type it has knows how to do this.
Further thoughts
Perhaps the clearest next step would be adding validation to field/form registration, since that lets field type creators verify field options without forcing them to duplicate code for different languages or render methods.
But the rest is unclear. It may only become necessary when developers begin writing their own custom field types---once that begins, we certainly won't be able to change our render method without breaking their fields.
Next steps
[ ] Determine the most forward-thinking render method
[ ] Add option verification to field registration?
Wordpress seems to be moving towards client-side rendering and a more JS-driven experience, and we should build the Fields API in a way that supports such an upgrade.
We currently lack a good solution.
The problem
The Fields API is not designed to handle the rigors of cross-language rendering (or even having multiple render methods at all):
choicesinWP_Fields_API_Multi_Checkbox_Control) are not sanitized or verified by default.echo-ing HTML.Possible solution
One solution is to build a pluggable render system:
That way we could render the "New Post" form by, e.g., outputting a JSON blob of the form data and enqueuing a script that rendered the form in React.
Caveats
This system, however, lacks a sensible modularity. There are two ways to implement a custom render system, and both have flaws for plugin authors:
Walker-render: a renderer must read the data representation and output form elements for each item.
The walker must know about every form type: what if a site that wants to use
CustomRenderWalkeralso usesCustomFormTypethatCustomRenderWalkerdoesn't know about? How can we handle this?Field-render: all fields render themselves (current implementation).
Each field type must know about all renderers: a site that wants to do a
Reactrender must ensure that each field type it has knows how to do this.Further thoughts
Perhaps the clearest next step would be adding validation to field/form registration, since that lets field type creators verify field options without forcing them to duplicate code for different languages or render methods.
But the rest is unclear. It may only become necessary when developers begin writing their own custom field types---once that begins, we certainly won't be able to change our render method without breaking their fields.
Next steps