Form Generator

[logaretm]

What

Form generators are an important part of the form ecosystem and having a way to generate it easily given a JSON schema or objects is usually desired especially in CRUD heavy applications.

Form generators at their simplest are just a loop iterating over an array of fields, at the simplest level it is a flat array of fields. It can be nested which will introduce a concept of groups and how they can be rendered, maybe it is a row? or maybe it is just a group.

How

Field Props

Regardless of the rendering mechanism (more on that below), we need to infer the following props from fields:

interface FieldProps {
  /* Is the field required? */
  required: boolean;
  /* The field name which will map its value to that path */
  name: string;
  /* The field label, required for a11y */
  label: string;
  // Other stuff like options for select fields, min/max for sliders, etc..
  // ...
}

There are other props, but they are mostly related to rendering.

Rendering (JSON AST)

Typically we can represent a generator schema with JSON object containing items that may look like this:

{
  type: 'checkbox',
  label: 'Drinks',
  name: 'drinks'
}

The type field would control which field to get rendered, this means the user will have to register types against their rendered fields of choice. Since formwerk can't possibly know which checkbox component to render when encountered in that place.

So a simple registration config file or a runtime config can easily tie in the various types and which components to render.

This would imply we need to come up with an AST that is type-safe, it should also be JSON-compliant so it can be serialized and stored easily.

Rendering (Standard Schema)

Another alternative to rendering is we can also use Standard Schema providers to render those fields. They almost fit the use-case but I think they will only work for small or simple flat forms. There is a couple of concerns:

• Paths vs Fields: Not all paths are represented by fields, a user.name path be a nested text field or an select field emitting objects as values. There is no way to know for sure which type to render in that case, especially when schemas are statically defined.
• No JSON AST for Standard Schemas yet: This is being discussed here, but this could be a blocker for taking up standard schemas as a way to render form fields.

There is a way to remedy these issues by adding extensions to the standard schema, like field markers and other metadata methods. But this will need to be researched.

I think we will have to do ASTs anyways since they are serializable, but it would be very cool to see what Standard Schema members will come up with and if there is a way to align with that early on.