Page MenuHomePhabricator

Add a returnType field to TemplateData
Open, Needs TriagePublicFeature

Description

Feature summary:

Add a returnType field to TemplateData to describe the type of value returned by a template. The field should accept the same values currently supported by parameter type fields (e.g. string, content, boolean, number, date, etc.).

For example:

<templatedata>{
	"description": "Returns the formatted name of a person.",
	"returnType": "string",
	"params": {
		"name": {
			"label": "Name",
			"type": "string"
		}
	}
}</templatedata>

Use case(s):

In some contexts, only particular types of values can be inserted. For example, inside an HTML attribute, a template returning a value of type content may produce invalid output:

<span class="<b>Hello world</b>">...</span>

where <b>Hello world</b> is the expansion of a template. In such a context, a template returning a plain string would be appropriate, while one returning arbitrary content would not.

Currently, TemplateData can describe the expected type of each parameter, but it cannot describe the type of a template's output. This means that tools consuming TemplateData have no way to know whether a template returns a string, content, a boolean value, or another kind of value.

Adding a returnType field would allow template authors to provide this information in a machine-readable way.

Benefits:

A returnType field would make TemplateData a more complete description of a template's interface. It would allow editing tools, documentation generators, and other consumers of TemplateData to better understand how templates can be used and combined.

This would also improve consistency by reusing the existing TemplateData type vocabulary rather than introducing a separate system for template output values.

Event Timeline

Are you thinking that this would be pure documentation-of-intent, or that there'd be validation and enforcement?

@DLynch

My main goal is documentation.

Right now, if I want to know what a template returns, I have to inspect its source code and infer it from the implementation (as a temporary workaround, I was actually thinking of creating a small “return type” banner for documentation pages to make this information visible without having to read the code).

Having returnType in TemplateData would provide a machine-readable way to document a template's output, just as parameter types document its inputs.

Validation or enforcement wasn't my primary motivation, although I think it could enable useful tooling in the future. For example, the Visual Editor (or other consumers of TemplateData) could warn when a template documented as returning content is inserted into a context that expects a plain string, such as an HTML attribute. But I'd see that as an optional downstream use.