Generate a dynamic web form from a user-supplied class type

[dselman]

Here's a checklist that may be helpful, based on the Composer metamodel:

Types of property in a ClassDeclaration:

• [ ] Primitive types: Integer, Long, DateTime, String, Boolean, Double
• [ ] Enum
• [ ] Relationship
• [ ] Concept (arbitrary nesting)
• [ ] All of the above can be arrays[]
• [ ] All of the above can be optional

For each of these, some thought should be given to the best UI widget to use for editing. For example, a calendar widget for DateTime, with optional support for specifying the timezone.

Abstract types

Types can be declared as abstract. It is not possible to create instances of abstract types, so the form generator should reject these. A class may, however, have a property that is an abstract type, in which case the instance must a concrete type that extends the abstract type. This code may be a helpful reference: https://github.com/hyperledger/composer/blob/master/packages/composer-common/lib/serializer/instancegenerator.js#L173

Relationships

For relationships we may need a mechanism whereby the host platform can supply instances (of which there could be many), so integrating with type-ahead completion and lazy loading may ultimately be required.

Validation

String properties can have a Regex expression attached, used for validation. We could enforce this regex in the form.

Numeric properties can have a range expression attached, used for validation. Depending on the size of the range, perhaps a slider UI could be used for Long/Integer types?

Localization

It would be very useful to be able to decorate the Composer model with annotations that are used as the labels for the generated form. See https://github.com/accordproject/cicero/issues/111. Additional annotations could be defined for accessibility, keyboard navigation etc.

Graceful Fallback

The form generation doesn't necessarily need to be able to handle all possible models (the arbitrary nesting may be a challenge to make usable), but it should degrade gracefully to a raw JSON input (syntax highlighting being a bonus).

[uchibeke]

For working on this, I am thinking of making components form components to be mapped each of Types. So a react form field component will be rendered depending on the field type. The dynamic form example was a good start. There are two ways I could approach this:

• Use an existing react npm package. react-form (https://www.npmjs.com/package/react-form) looks good
• Build each component from scratch with validation etc

Are there some tradeoffs of doing the former?

[penguinbroker]

An existing library can certainly make using this easier, but it also forces users of this library to adopt certain patterns. In this case there may be someone that would like to use this but is not using react.

Stripe takes a good (imo) approach to this. They provide a low level javascript library in Stripe.js and a react wrapper in https://github.com/stripe/react-stripe-elements. We could take a similar approach here, start by building a vanilla javascript solution then build the react wrapper for it.

It's important that users are able to customize the look and feel of the generated form.

Also good to minimize the dependency tree as much as possible so that users can keep their production builds as lightweight as possible.

[dselman]

Added more details on abstract types.

[uchibeke]

@penguinbroker, I looked at the stripe elements react repo to try to understand how the react version works with the low level javascript library, Stripe.js. I was, however, unable to find the code for the low level javascript library that the react version is wrapping around. It all looks like react code. Could you point me to the code for that, please?