You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One cool thing about FVTT's data model is that it exposes certain kinds of field metadata at run time. Aside from things like min and max on number fields, every field can take a label and hint property. Internally, FVTT generates many form elements by looking at these properties.
I reckon the same basic principle could be applied with Vue components. The basic component could look at a given data path, get the document's relevant value and its field instance, and automatically configure the proper events, labels, ARIA annotations, and tooltips needed to manage the field data. It wouldn't be able to cover every last case, but it would cover a lot of them.
It'd also make the data model the "single source of truth" for field labels/definitions... but, honestly, I don't hate that.
I'm imagining props that look something like this:
interfaceIronFieldProps<SourceData=unknown>{key: string// e.g. "system.description"document?: foundry.abstract.Document<any,any,any>// in case you want to override the injected documentupdater?: (newValue: SourceData)=>void// in case you want something other than `document.update({[key]: newValue})`updateEvent?: string// in case you want to override the default event that triggers an update}
That could be extended and plugged in to e.g. <IronStringField> to manage a StringField, <IronHtmlField> to manage an HTMLField, <IronNumberField> to manage a NumberField, and so on.
The components might render different HTML elements depending on the field options. For example, a StringField with the choices option would render as a <select>-like element, but in most other cases would appear as a <input type="text">.
The text was updated successfully, but these errors were encountered:
One cool thing about FVTT's data model is that it exposes certain kinds of field metadata at run time. Aside from things like
min
andmax
on number fields, every field can take alabel
andhint
property. Internally, FVTT generates many form elements by looking at these properties.I reckon the same basic principle could be applied with Vue components. The basic component could look at a given data path, get the document's relevant value and its field instance, and automatically configure the proper events, labels, ARIA annotations, and tooltips needed to manage the field data. It wouldn't be able to cover every last case, but it would cover a lot of them.
It'd also make the data model the "single source of truth" for field labels/definitions... but, honestly, I don't hate that.
I'm imagining props that look something like this:
That could be extended and plugged in to e.g.
<IronStringField>
to manage aStringField
,<IronHtmlField>
to manage anHTMLField
,<IronNumberField>
to manage aNumberField
, and so on.The components might render different HTML elements depending on the field options. For example, a
StringField
with thechoices
option would render as a<select>
-like element, but in most other cases would appear as a<input type="text">
.The text was updated successfully, but these errors were encountered: