Open hexus opened 5 years ago
Allowing layout to be defined separately means data structure doesn't need to be tied to layout.
This may add complexity, but improves versatility and separation of concerns (data vs. presentation). It means that markup wouldn't be the only way to define form layout; it can be data-driven.
<pragma-fields fields="..." layout="..." data="..."></pragma-fields>
If no layout is provided, it can be generated from the field set.
The real question is how different a layout object structure would look, and what they would be allowed to override. For example, it'd make sense for a layout field to override a field's input type, but probably not its actual data type.
Integrating Stencil with the webpack build process to avoid two separate pipelines and NPM projects. Ouch.
Mapping fields, in <pragma-form>
, to arbitrary HTML elements. :thinking:
Perhaps only:
field
property of any element in case it understands Pragma fields. Doesn't feel great, but what else can be done?A registerFieldElementMapping()
method, or similar, on <pragma-form>
might be the best way to do the latter, above. It would allow field mappings for custom elements can always be defined somehow.
Extending built-ins with Stencil: https://github.com/ionic-team/stencil/issues/1382#issuecomment-833095324
A set of web components could be used to either fully render a form, or selectively render parts of a form. Using field definitions for layout is then optional.
<pragma-form>
would be a decorator element that propagates field data to any relevant children, internally managing a PragmaForm
instance.<pragma-form>
and<pragma-fields>
elements could optionally load field sets by themselves.