Pitch - JSON Approach For the Fields API

[alexstandiford]

I started working on a very rough PoC earlier this week, and it helped me form an opinion on how I think the fields API could work. I think there's some pretty good ideas here that would allow us to implement the fields API without disrupting WordPress backcompat.

The key component of this approach is that the rendering is completely decoupled from the fields. This allows us to register fields without trying to wrangle the disparate methods in which WordPress currently outputs HTML in the process. Further, the approach allows us to inject this into existing locations without requiring significant refactors in the process.

My hope is that this discussion will help kick off discussions about the individual components that would ultimately make up the fields API. This would allow us to break this project into smaller pieces, and enable us to split up into multiple teams to work on the individual pieces. With this clarity, perhaps it could also open up opportunity for buy-in from other teams, such as the people working on the new admin UI, or Gutenberg itself.

Most of this content came from discussions that have happened inside the core-fields channel in Make WordPress. If you're interested in contributing more, I encourage you to join there since we've been talking about this topic quite a bit lately.

Goals

The primary goal of the Fields API is to make it possible to register, and display fields anywhere in WordPress, through JSON files. These JSON files should be able to sufficiently describe fields, and allow these fields to be displayed throughout WordPress without writing any PHP or JavaScript.

It should be able to be used throughout the existing WordPress interfaces, as well as be something that can be used in future interfaces. Further, it should be relatively easy to introduce the fields API anywhere, and should not require significant refactoring to add.

The JSON

The goal of JSON file is to make it possible to completely describe any set of fields within WordPress. This should allow you to:

1. Describe where the data for the field is saved
2. Describe validations that ensure the field can be saved.
3. Describe where the field should be rendered.
4. Provide any information about the field to allow it to be rendered in either PHP or JavaScript
5. Provide conditionals that prevent the field from displaying.

The JSON below is absolutely not complete. This is just a starter point to start thinking through how it can be used.

[
  {
    "id": "email_field_example",
    "description": "A basic email field sample",
    "datastore": {
      "type": "option",
      "data_type": "string",
      "default": "default-value",
      "validations": [
        {
          "type": "has_role",
          "role": "administrator"
        },
        {
          "type": "is_email"
        }
      ]
    },
    "locations": [
      {
        "id": "permalink_settings",
        "control": {
          "type": "text_input",
          "html_type": "email",
          "disable_if": [
            {
              "type": "missing_role",
              "role": "administrator"
            }
          ],
          "hide_if": [
            {
              "type": "missing_role",
              "role": "administrator"
            }
          ]
        },
        "priority": 10
      }
    ]
  }
]

Now there's a lot going on in this JSON, so let's break it down into pieces.

Datastore

The datastore portion of the JSON determines where the field saves the data. There can be any number of datastore types, and they would need to somehow be registered in PHP, probably using some kind of abstract class or interface that has a set of specific methods that enable the crud operations against the datastore.

Perhaps something like this:

register_datastore_type( 'datastore_name', Some_Datastore_Handler::class );

Where Some_Datastore_Handler is a class that gets instantiated with the JSON data, and that information is used to help inform how to save the data.

Validations

The datastore could also support an array of "validations", which can also be registered, and have their own handlers to validate. You'll see these validation types show up in other places, as well, and are intended to serve as a way to make a pre-made conditional usable inside the JSON. In this case, if the person does not have the role of administrator and the input value is not a valid email, validation would fail and the content would not be saved.

Perhaps something like this:

register_validation_type( 'validation_name', Some_Validation_Handler::class );

Or maybe a functional-based approach:

register_validation_type( 'validation_name', function( $data ){
    // Do validation
} );

Ultimately, this should be able to do all basic CRUD options for any given field, and make the validations necessary before saving to ensure that it should save.

"datastore": {
  "type": "option",
  "data_type": "string",
  "show_in_rest": true,
  "default": "default-value",
  "validations": [
    {
      "type": "has_role",
      "role": "administor"
    },
    {
      "type": "is_email"
    }
  ]
}

Locations

Locations could be an array of places in-which the field would be rendered throughout WordPress.

"locations": [
  {
    "id": "permalink_settings",
    "control": {
      "type": "text_input",
      "html_type": "email",
      "disable_if": [
        {
          "type": "missing_role",
          "role": "administrator"
        }
      ],
      "hide_if": [
        {
          "type": "missing_role",
          "role": "administrator"
        }
      ]
    },
    "priority": 10
  }
]

Controls

Each location would be associated with a control. Just like validations and datastores, these controls could be registered, and then associated with a class interface that is instantiated with the JSON data. This data is then used to parse, and provide the information about the control, which enables whatever is being used to render the content to actually do the rendering.

Perhaps something like this:

register_control_type( 'control_name', Some_Control_Handler::class );

Note that in this concept a control does not actually render the content. It is intended to instead describe the field to whatever is doing the rendering. The control type would use the input data from the JSON to provide the actual information for the control.

The control above includes hide_if and disable_if validations, which could work with the same validation types as discussed above. This allows us to signify if a field should be conditionally hidden, or if a field should be disabled.

Rendering These Locations

Fields for a location could be registered, and then rendered inline by either calling a PHP function, or a React component:

echo get_field_location( 'permalink_settings' );

<Fields location="permalink_settings"/>

Behind the scenes, these functions would need to:

1. Gather all of the fields whose location is configured to render at the specified location
2. Loop through each field in the correct order, and render the markup needed for that field.

In either case, we would probably need to somehow map field control types to different markup strategies. In React, this could be a component. In PHP, we would probably need to create something to handle this since there isn't a standard way to do that right now.

In the case of the block editor, we could ensure the fields render quickly by adding them as preloading middleware for the field data, but that's just a suggestion 😄.

Working With Fields

I think it's important that the fields API allows us to work with these fields both in PHP and with the REST API. I believe this is what will enable the system to work well inside the block editor, modern admin interfaces, future iterations of the WordPress app 🤞, while also enabling us to create backcompat layers with existing systems, should we choose to do any refactoring (although this probably isn't going to be necessary.

While this is definitely not complete, some things that I think we would need include:

1. Get all of the fields for a specific location.
2. Get a single field's data based on the field ID
3. Do basic CRUD operations with a single field, or a batch of fields
4. Run validations against a field, without saving. This allows us to validate a value on-blur.

It could be really useful to have a registry query function that could be consistent with how other query objects work. something like:

$fields = new Field_Query( [
	'location' => ['id' => 'permalink_settings'],
] );

Which would yield an array of Field objects that are in the permalink_settings location.

[ohryan]

I really like this pitch.

I wonder if some of the properties can be decoupled to define a flatter JSON?

• Are validations dependent on the datastore? Or is validation the same across all implementation?
• Do different locations have different controls? Or does the the field have the same controls in all contexts?

[cr0ybot]

I had similar thoughts. I realize it narrows the possibility space but I'd prefer a flatter approach as well, in particular putting validations and control at the top level. That way validation is consistent and we don't have to deal with repeating control definitions for different locations. I have a different thought about locations but I'll post that as a separate top-level comment.

[alexstandiford]

Are validations dependent on the datastore?

In the example above there's two different places validations are used, however they serve two different purposes.

The validations that are nested inside the datastore would prevent the field from being saved if those validations fail.

The validations that are nested inside the locations hide_if and disable_if properties of the different locations would cause the field to either hide, or be disabled if those validations pass.

So in this case, I think they both are dependent on their respective locations.

Do different locations have different controls?

At least right now, I have them set to use different controls. The thinking is that the rendering that goes into different locations may differ from one field to the next. I could definitely see this being extracted and put at the top level instead of being location specific. It's possible to do both, even. Perhaps the top-level control is the "default", and any location that specifies a control at their level overrides the parent control.

[cr0ybot]

On Locations and Field Groups

This approach to field definition is very bottom-up, which is to say that the field is an entity that can be rendered in any number of places. While I think that approach has merit, I believe most existing field plugins approach field definition from the top down: location-specific groups of fields are defined, into which controls are added. I think we need to make a determination on which approach is most suitable for all the various ways we expect this to be used.

One point in favor of a "field group" approach is the potential for in-group conditional rendering. While it would be very impractical for any individual field to conditionally render based on another field that may or may not be present at a location, defining groups of fields together allows for co-location of conditional logic* between fields.

Another point of concern I have is defining datastores per field. I think it's likely that the datastore would be highly coupled to the location a field or group of fields is rendered. For instance, rendering fields on the edit screen for a particular post type likely means the datastore is post meta--and let's not forget that we may need some special conditions for certain locations, like post_type = post. I wonder then if, apart from registering datastores, locations could also be registered to couple them with a particular datastore instead of having to define this coupling for each and every field.

*This is a bit of a tangent, but considering conditional logic has me realizing that pure PHP rendering of field markup will likely not be enough, and we might benefit from jumping straight into a system based on React for field rendering, since we know the admin is going that direction anyways.

[cr0ybot]

I should have clarified that I don't think a field or field group should be confined to a single location. Being able to attach the field or field group to multiple locations should definitely be in-scope.

I'm also referring to the notion of "location" in an abstract sense. I think we probably agree but I should clarify here just to be sure. A "location" is simply a named bucket that can be filled with fields, and this bucket must be explicitly rendered after being fetched by name. So, a WordPress admin settings screen might grab several named location buckets to render on a particular screen.

So when I say that a location ought to be coupled with a datastore, I mean it in this abstract sense, though there may be specific named locations that core WordPress creates and renders in specific places.

Bearing this in mind, an example use-case might be defining the same set of fields for a post type and also a taxonomy term. Let's assume that core has defined separate locations for these already, so all a user of this API needs to do is define their fieldset and attach it to post_type=foo and taxonomy=bar, and the locations, by their attachment to post meta and term meta respectively, handle the storage in the correct places automatically.

In the case of your custom plugin (I apologize if I mischaracterize it here), you might use an existing core location for global settings (a Customizer location?) that is preconfigured to use the settings/theme_options datastore, and then opt to use core's post_type location for per-post/page settings that is preconfigured to use the post meta datastore, no custom post type required (unless I am missing something here).

You are also free to register your own datastores (I would assume this would be rare unless a plugin uses custom tables or perhaps a third-party API) and also register your own locations that connect to those stores, whereby you'd also be responsible for rendering those locations. So in a sense I'm advocating for rendering to be based on these location "buckets" and not as individual fields.

[alexstandiford]

A "location" is simply a named bucket that can be filled with fields, and this bucket must be explicitly rendered after being fetched by name

Yep, that's fundamentally what I'm thinking, as well.

In the case of your custom plugin (I apologize if I mischaracterize it here), you might use an existing core location for global settings (a Customizer location?) that is preconfigured to use the settings/theme_options datastore, and then opt to use core's post_type location for per-post/page settings that is preconfigured to use the post meta datastore, no custom post type required (unless I am missing something here).

Apologies if I misunderstand here, but I think the problem I would have with this approach is that it would require that the data is stored in two different places - the post type, and the customizer theme options. What I would want to do in this case is use the same single source of data in both locations. In my case, the ideal location for this is either in theme options, or the options table.

In my head, a field in the context of the fields API is defined as a single piece of data that can be accessed and manipulated anywhere in WordPress., but we can challenge that assumption.

It seems that one potential disadvantage of the approach I have proposed right now is that there isn't a way to make a group of fields that behave in the same way store in different datastores. One potential solution to this could be to make the fields support multiple datastores, and require that locations specify which datastore they should use.

Roughly speaking, something like this, where the datastore to use is declared in the location:

[
  {
    "id": "email_field_example",
    "description": "A basic email field sample",
    "datastores": [
      {
        "id": "settings",
        "type": "option",
        "data_type": "string",
        "default": "default-value",
        "validations": [
          {
            "type": "has_role",
            "role": "administrator"
          },
          {
            "type": "is_email"
          }
        ]
      },
      {
        "id": "meta",
        "type": "meta",
        "subtype": "post",
        "post_type": "page",
        "data_type": "string",
        "default": "default-value",
        "validations": [
          {
            "type": "has_role",
            "role": "administrator"
          },
          {
            "type": "is_email"
          }
        ]
      }
    ],
    "locations": [
      {
        "id": "permalink_settings",
        "datastore": "meta",
        "control": {
          "type": "text_input",
          "html_type": "email",
        },
        "priority": 10
      },
      {
        "id": "permalink_settings",
        "datastore": "settings",
        "control": {
          "type": "text_input",
          "html_type": "email",
        },
        "priority": 10
      }
    ]
  }
]

Another thing we could do, is make datastores optional, and use a sane default datastore for locations. This could potentially remove the need to specify where to save the data in most common use-cases, however I'm not entirely convinced this is a good idea since most datastores should be adding at least some kind of validation, and if nothing else they would at least specify the type for the field. This would also require that every location that is registered to the API provides a default datastore, which does make registering locations a little more complex. Those disadvantages might be worth it though, considering a potential JSON could look like this as a result:

[
  {
    "id": "email_field_example",
    "description": "A basic email field sample",
    "locations": [
      {
        "id": "permalink_settings",
        "datastore": "meta",
          "type": "text_input",
          "html_type": "email"
        "priority": 10,
      },
      {
        "id": "permalink_settings",
        "control": {
          "type": "text_input",
          "html_type": "email"
        },
        "priority": 10
      }
    ]
  }
]

[alexstandiford]

But even as I talk about this, it doesn't seem like that solves your problem, either does it? You'd still need to repeatedly add the datastore information in each field you register, and a lot of that information could potentially be the same info. That's kinda annoying.

How can we reduce the amount of repetition in the JSON while still ensuring the flexibility that we desire?

[cr0ybot]

I think in my scenario regarding your plugin, if you didn't want per-post post meta storage, you could define a custom location that uses the same datastore as the other global settings, and maybe there would be a location renderer helper that you could call to make it show up where you want in the editor/in a block like you suggested in the first post.

Regardless, reducing repetition would be awesome. Boilerplate is the bane of my existence. Not only is it annoying to write every time, but it introduces more opportunities for human error.

Maybe part of the reason I'm thinking about datastores and locations being coupled like this is because I don't quite fully grasp the implications of having, say, a screen full of fields that are all connected to different datastores and how that would be handled by the back-end. At least with a coupled approach, you know that all of the data within a defined location only requires one connection to a particular form of storage, even if there are multiple calls/queries to store that data.

Another thing to be very conscious of is that I'm coming from the perspective of ACF and obviously have a bias towards that system, but that might not be the most useful way to go about creating a foundation that plugins like ACF could build upon. I still think it would be nice to be able to interact with this system without needing a plugin to surface it. I'm also not sure, getting back to JSON specifically, how much this steps on ACF's toes, or if that even matters.

[alexstandiford]

you could define a custom location that uses the same datastore as the other global settings

I think for me the sticking point is the idea of binding a location to a datastore. I don't see any reason why it has to be bound to the location, but I can see plenty of reasons why I wouldn't want it to be bound to the location. I 100% agree about reducing boilerplate, and I think binding the location to the datastore might help with that some, but I think that the cost of that change in-terms of flexibility is too great.

I've been thinking about how we can reduce the boilerplate, however, and I think there's a couple of ways we could potentially accomplish this without binding the datastore to the location.

Register a custom datastore that pre-fills values to make re-using it easier:

// Registers a post meta field as a string value
register_datastore_type( 'string_post_meta_field', String_Post_Meta_Field::class );

class String_Post_Meta_Field implements Datastore_Type{
    /*...*/
    protected function init(){
        register_meta( 'post', $this->id, ['type' => 'string', 'show_in_rest' => true, 'default' => 'default-value']);
    }
    /*...*/
}

By doing that, we can cut down on the JSON for the datastore significantly, since the custom datastore type pre-fills a lot of the settings, like data_type, show_in_rest, and the other things needed to register a piece of metadata. This would cut back on the repetitive boilerplate significantly. I'd imagine that the data that is provided to the datastore JSON would be passed to the corresponding class as an array of arguments in the constructor, so a class could do just about anything with the json information, but that's just one way to do it.

"datastore": { "type": "string_post_meta_field"}

Related Idea - Make it possible to register datastores in JSON

We could also set up the JSON so that the top level can create pre-made datastores that can be used as "templates" of a sort.

{
  "datastores": [
    {
      "id": "string-option",
      "type": "option",
      "data_type": "string",
      "default": "default-value",
      "validations": [
        {
          "type": "has_role",
          "role": "administrator"
        },
        {
          "type": "is_email"
        }
      ]
    }
  ],
  "fields": [
    {
      "id": "email_field_example",
      "description": "A basic email field sample",
      "datastore": "string-option",
      "locations": [
        {
          "id": "permalink_settings",
          "control": {
            "type": "text_input",
            "html_type": "email",
            "disable_if": [
              {
                "type": "missing_role",
                "role": "administrator"
              }
            ],
            "hide_if": [
              {
                "type": "missing_role",
                "role": "administrator"
              }
            ]
          },
          "priority": 10
        }
      ]
    }
  ]
}

We could expand on that and make it so that a field can use a datastore as a template, but override some parts. The example would override the default value for the field:

{
  "datastores": [
    {
      "id": "string-option",
      "type": "option",
      "data_type": "string",
      "default": "default-value",
      "validations": [
        {
          "type": "has_role",
          "role": "administrator"
        },
        {
          "type": "is_email"
        }
      ]
    }
  ],
  "fields": [
    {
      "id": "email_field_example",
      "description": "A basic email field sample",
      "datastore": {
        "id": "string-option",
        "default": "a custom default value"
      },
      "locations": [
        {
          "id": "permalink_settings",
          "control": {
            "type": "text_input",
            "html_type": "email",
            "disable_if": [
              {
                "type": "missing_role",
                "role": "administrator"
              }
            ],
            "hide_if": [
              {
                "type": "missing_role",
                "role": "administrator"
              }
            ]
          },
          "priority": 10
        }
      ]
    }
  ]
}

Maybe part of the reason I'm thinking about datastores and locations being coupled like this is because I don't quite fully grasp the implications of having, say, a screen full of fields that are all connected to different datastores and how that would be handled by the back-end.

I imagine that a datastore would be associated with a class of some sort. That class would contain the methods needed to handle saving that field. Bulk saving doesn't really happen in WordPress currently, so looping through each field and running $field->datastore->save(). Think of it as a sort-of service provider, where the instantiated Field class would contain the datastore instance needed to handle the CRUD actions for that specific field.

A simplified PHP example function might look something like this:

function save_fields(array $fields){
    foreach($fields as $field){
        $field->save();
    }
}

This function would be somehow hooked into the different save actions on different screens, and somehow know how to get the fields from the input.

[borkweb]

I agree with all of you: Having a JSON representation of the fields will be key for being able to leverage the Fields API in both the PHP side of the house as well as the Block & Site Editor. I have a couple of thoughts that might be worth some discussion:

Forms are more than just the fields

While this is a Fields API, whatever we build needs to keep in mind that it will power forms and forms need more than just fields. We need an API that supports the injection of non field-related elements so that we can reduce the overhead of generating forms.

PHP first, JSON second

Hand-built JSON can introduce confusion for developers and unpredictability with initializing a field set because, well, humans are humans and it is easy to misread/add a typo/etc. Building out a JSON file requires knowledge (or a reference) of the structure and meticulous attention to ensure a properly formatted result.

A PHP-first API would allow:

1. IDEs to inform developers of what is possible
2. PHP to deal with error handling and validation of API usage
3. Provide more opportunities for injection and manipulation of fields, field order, data, etc
4. Avoidance of unnecessary error handling caused by malformed Fields API JSON

GiveWP's approach feels fairly approachable from the Fields API kick-off call earlier this year. Here's a potential example using some of the naming conventions proposed above:

use WpOrg\Fields\Location;
use WpOrg\Fields\Section;
use WpOrg\Fields\Text;
use WpOrg\Fields\Email;

$location = new Location( 'some-form' );
$location->append(
    Section::make( 'the-section-id' )
        ->append(
            Text::make( 'first_name' )
                ->label( __( 'First Name', 'whatever-textdomain' ) )
                ->rules( 'required', 'max:255' ),

            Text::make( 'last_name' )
                ->label( __( 'Last Name', 'whatever-textdomain' ) )
                ->rules( 'required', 'max:255' ),

            Email::make( 'email' )
                ->label( __( 'E-mail', 'whatever-textdomain' ) )
                ->rules( 'required', 'email' ),
        )
);

From a PHP API, the fields would be serializable.

$json = $location->jsonSerialize();

[
	{
		"name": "the-section-id",
		"nodeType": "group",
		"type": "section",
		"nodes": [
			{
				"name": "first_name",
				"nodeType": "field",
				"type": "text",
				"label": "First Name",
				"defaultValue": "",
				"helpText": "",
				"placeholder": "",
				"readOnly": false,
				"validationRules": {
					"required": true,
					"max": 255
				}
			},
			{
				"name": "last_name",
				"nodeType": "field",
				"type": "text",
				"label": "Last Name",
				"defaultValue": "",
				"helpText": "",
				"placeholder": "",
				"readOnly": false,
				"validationRules": {
					"required": true,
					"max": 255
				}
			},
			{
				"name": "email",
				"nodeType": "field",
				"type": "email",
				"label": "E-mail",
				"defaultValue": "",
				"helpText": "",
				"placeholder": "",
				"readOnly": false,
				"validationRules": {
					"required": true,
					"email": null
				}
			}
		]
	}
]

Handling datastores

With a OO PHP API, we could create field objects with traits (perhaps similar to Give) and explicitly indicate that specific fields should be fetched and persisted in specific locations.

Visibility conditions

Likewise, with OO PHP, we can have some very flexible approaches to field visibility, leveraging values from other fields, closures, etc.

$form->append(
	Checkbox::make( 'sandwich' )
		->label( 'Get a sandwich?' ),
		->checked( false )
		->value( 'yes' ),

	Select::make( 'bread' )
		->showIf( 'sandwich', '=', 'yes' )
		->options( [
			'wheat' => 'Wheat',
			'white' => 'White',
			'rye'   => 'Rye',
		] ),

	Checkbox::make( 'super_deluxe' )
		->label( 'Make it super awesome?' ),
		->checked( false )
		->value( 'yes' )
		->showIf( 'is_admin' ),

	Checkbox::make( 'wrapped_in_wax_paper' )
		->label( 'Wrap it in wax paper?' ),
		->checked( false )
		->value( 'yes' )
		->showIf( function() use ( $some_other_thing ) {
			return is_admin() && $some_other_thing;
		} )
);

[gaambo]

I agree with you that a fluent OOP PHP API definately allows for better DX and is beautiful to use. Just wanted to add, that JSON with published shemas allows for some great IDE integration and doesn't have to be "loose" or (as) prone to errors. theme.json and block.json already are using this (see here for theme.json and here for block.json). So this is a schema which describes how the JSON must look like and IDEs (like VS Code) give you autocompletion / Intellisense when writing those JSON files.

[ohryan]

While this is a Fields API, whatever we build needs to keep in mind that it will power forms and forms need more than just fields. We need an API that supports the injection of non field-related elements so that we can reduce the overhead of generating forms.

Handling non-fields seems - by definition - out of scope of a fields API. Could you share a use case/example?

[borkweb]

My motivation for that little blurb is based on my perception (which others may not hold) that fields in isolation aren't all that exciting or useful without the concept of a form. Rendering a form powered by a Fields API that doesn't support arbitrary items (like headers, paragraphs, whatever) would become a much more complicated task than if we baked support for arbitrary elements into the API.

Example

Let's say the Fields API doesn't support arbitrary elements but I want to inject a paragraph between a couple of the fields when I'm rendering my form. If I have 10 fields in my Form (or Location or whatever we call it), I would have to resort to filtering in order to inject the paragraphs. If I want those paragraphs to exist in a PHP rendered output and in the Block Editor, my work becomes even more complicated.

Instead, if we support arbitrary elements, we can include them during the declaration step of the form and the content/values will be present for any rendering logic that we build. We would still have filters, of course, but for default form functionality, they wouldn't be needed.

[ohryan]

It sounds like you're describing something more akin to a Forms API.

In my mind, the Fields API would be an abstracted API solely focused on fields. The Fields API will be able to power fields where entire forms aren't required (ex. options in the block editor sidebar).

A Forms API could be build on top of the Fields API to provide developer experience you're describing.

But it's important to separate concerns and abstract individual needs.

[sc0ttkclark]

I think the ability to have Heading, Separator, HTML, etc field types is something already embraced by most form building plugins and APIs (including ACF and others).

Those fields would not pull or save data from the DB and I think that's something we can easily account for in our efforts.

[nikmclaughlin]

👋 New and catching up here, but I'm not sure about the inclusion of "location" data in the field definition 🤔 It seems to me that locations are collections of fields that are mostly useful when rendering. I don't see a use case where we'd need to check all the different locations that a particular field is registered in, rather the most obvious need would be the inverse: getting all the fields that are registered for a particular location. What's more, I think the definition of the field itself should be independent of whatever locations it's registered in in order to fully decouple field definition from rendering.
With that all in mind, I think we'll need to define fields and locations separately (and possibly forms/fieldsets as well). I'm still catching up on the existing research, so not ready to propose my own solutions there, but wanted to share the thoughts at least for now :)

[cr0ybot]

@nikmclaughlin I agree that field definition should be independent of the location it's rendered in (I don't want different fields for the same data in different places, I want the same field), but I still think that, for a JSON API, we should be able to define the field(s) and where they should appear all in one go. We may not necessarily think we need to get all locations that a field appears in (at least for now?) but we do need to know what fields should be rendered for each location. I don't think I'd like having to name every field that should be rendered in some separate "location" JSON or PHP method call, for instance, if naming the locations for the field in the field JSON would automatically register the field(s) to those locations.