Dynamic Forms Component

[kyleledbetter]

Possibly based off https://github.com/formly-js/ng2-formly

[KiaraGrouwstra]

Ignoring implementations for a second, I'd be curious as to your stance toward JSON Schema as a potential base to generate forms from (or probably extended, as form libraries building off of it have generally done so far). Not that it is the only such OIM, but I'm not sure of good alternatives.
Pros would be existing adoption as a way to express valid (input) values, plus being fairly expressive for validation.

If you would be interested in JSON Schema, I fear Formly isn't ideal for it since (1) you'd need to support it at the core to keep individual ng2 controls aware of validation bits they're responsible for, while (2) they want to remain OIM-agnostic (can't say put UI customization metadata into nested fields part of an array/object).

angular-schema-form and react-jsonschema-form were made for JSON Schema, but even the former hadn't really gotten an ng2 implementation yet.

Essentially I've been trying to do this right with JSON Schema and ng2, so would be curious as to your needs here.
(Also, having found Covalent I'm excited to migrate to it since Material2 hasn't really reached parity with 1 yet. Thanks for the awesome project.)
Don't look for code yet though; I'd need to first separate it from the rest of my project. Hence my wanting to check if you'd be interested at all first. Because yeah, even lacking proper OIM integration Formly would remain a valid alternative.
... Though maybe I should get things ready and make a demo first.

[gnomeontherun]

We haven't put together a comprehensive plan for forms yet, so this is interesting input. We know that Formly is interesting, but it does focus on some different things (like being able to template with various types of UI libraries instead of just material).

One example for our applications will be to have a JSON object define the form so it can dynamically generate all of the fields (I'm not familiar with the term OIM but this seems to be very similar). We have an existing API that defines these fields and generates a form, that we'll want to upgrade to work with Covalent. There is some discovery here for us to understand the constraints and challenges.

So yes, in general we're looking at a solution that marries together material form components and a JSON schema. If you have some design concepts or want to collaborate with this, we'd be happy to do some prototyping to see what we can figure out. This is likely one of those types of features that we'll build a simple solution that will need many iterations to polish for a more broad consumption.

[KiaraGrouwstra]

Yeah, I don't think anyone had heard of OIM, I also just found it on Formly's page linking to the above-mentioned podcast, which might have coined it. Since the podcast mentions multiple, them taking it from there probably also explains Formly's stance in not picking sides.

In reality it's a much smaller space though -- the Jsonary mentioned in the podcast seems to be a UI library (afaict on the level of angular-schema-form) for lack of a better term using JSON Schema itself, while that Metawidget appears to have a JS port, but appears very simple afaict (apparently focusing solely on generating some inputs with default values, they don't seem concerned with validation). JSON Schema on the other hand has been used for validation purposes by some API specifications like OpenAPI (née Swagger) and JSON API. The former was my use-case, to give context to my own bias. If you're coming from your own API as a use-case, you may consider checking them out too. :)

That isn't to say Formly doesn't have its own strengths compared to JSON Schema -- they were based on JS vs. JSON respectively, and the former obviously makes it easier to pass custom validation functions. That being said, existing form generation libraries have usually been inclined to add UI customization options on top, and I suppose at that point allowing JS objects (rather than just JSON serializations) so as to support custom validation functions should work just as well. I'll have to admit I'm not terribly familiar with Formly though, so there may be other relevant considerations. Any fields used in their example (className, label, placeholder, validation, that type to pick the template) look pretty relevant though, so you shouldn't have to give up on functionality like that in a forms implementations.

API endpoints' request GET parameters essentially just form one object (i.e. some keyed values), which without nesting (-> no arrays/objects) is relatively straight-forward. I already needed more if just to allow specifying request headers though (-> object). This shows where it can get harder -- taking into account parts of JSON Schema like:

1. such arrays/objects (should use their own custom ng2 form controls),
2. schema recursion (requires a lazy approach, can't just pre-generate form controls),
3. wildcard schemas ({} / type: 'any').

react-jsonschema-form and angular-schema-form both did 1, forgot about 2, neither did 3.
My own implementation so far consists of ng2 components + related form controls (for e.g. arrays, checkbox sets, objects either allowing schema swap on key change or structured to separate JSON Schema's properties/patternProperties/additionalProperties), lazily generated to solve 2.
Right now I'd just about tackled 3, which should allow generating UIs to edit the schema itself as well -- forms to generate forms to generate the input data you want, a bit like Kinto's formbuilder in React land based on that react-jsonschema-form.

As you're saying, you'd probably manage with something simpler as well. I'll try to see if I can migrate to Covalent and split my UI generation off for you to try, but failing that, you can check my components and controls for reference. I also just found this angular2-schema-form that may interest you as well.

[gnomeontherun]

I've had it in the back of my head that we'll essentially model an object that follows the properties set forth by HTML form elements. I think that will be most useful going forward, and allow us to keep it thin. You're raising a number of things that I suspect will have to be iterative releases to figure out.

This all really has to come in line with a REST API. Without clearing up the way the frontend and backend (regardless of platform) will both handle validation rules, I fear we're a few steps ahead on this discussion from our perspective.

[KiaraGrouwstra]

Yeah, fair enough.
Is there perhaps a place I could find documentation on your API(s)? I'd be interested in checking it out a bit further as well.

You mentioned doing a thin wrap of HTML form element properties -- which I guess might extend to wrapping Material components for their abstractions/additions. So this page contains a form example:

<form>
  <md-input style="margin-right: 20px;" placeholder="Company (disabled)" disabled value="Google"></md-input>
  ...
</form>

From your description I'm imagining a JSON-like equivalent like this, probably missing your intention...:

<covalent-form elements="[
  { elem: 'md-input', props: { style: 'margin-right: 20px;', placeholder: 'Company (disabled)' disabled: null, value: 'Google', transcluded_text_and_elements: [] } },
  ...
]"></covalent-form>

[gnomeontherun]

We don't have any documentation publicly about the API yet. That is a similar JSON example, though I don't have the specifics in mind yet.

[KiaraGrouwstra]

Alright. Curious how things will develop. :)

[KiaraGrouwstra]

Based on your thin wrapper comment, you may be also interested in this thread for examples of a few similar projects.

[emoralesb05]

Proposed first iteration on schema (used as our internal projects):

{ 
  name: string, // unique name used to get value and name control in form
  type: string, // 'text' , 'number', 'date', 'boolean'
  max: number | ISODateStr, (only applicable when number or date)
  min: number | ISODateStr, (only applicable when number or date)
  minLength: number, (only applicable when text)
  maxLength: number, (only applicable when text)
  required: boolean, // require value to validate form
  default: any // initial value of component
}

[KiaraGrouwstra]

Guess that pretty much matches the html input attributes, so for internal implementation that should make things easy.
So for required/maxlength/minlength (note html uses lowercase on them) ng2 has validator directives that'll stick on to the html attributes; for min/max I guess the number inputs may help restricting input values as well.

In the event you'd be willing to put up with the native Date input, material2's md-input might be close to meeting your stated initial requirements.

That said, they wouldn't do boolean either (delegated to checkbox/toggle), so you might just wrap them and swap input based on type.
I guess that also forms the core principle of my own project (particularly my InputField component, if not yet using Material2/Covalent), though I'd extended it to include array/object structures.

[emoralesb05]

Closing this since initial release will be in 0.10.

Please open a new issue for enhancements.