This patch wires up a Select and a Multi Select box. This patch also
establishes a decision as it relates to Formly TypeScript / gRPC Proto3
/ CUE definitions of the form data structure. The decision is to use
gRPC as a transport for any JSON to avoid friction trying to fit Formly
types into Proto3 messages.
Note when using google.protobuf.Value messages with bufbuild/connect-es,
we need to round trip them one last time through JSON to get the
original JSON on the other side. This is because connect-es preserves
the type discriminators in the case and value fields of the message.
NOTE: On the wire, carry any JSON as field configs for expedience. I
attempted to reflect FormlyFieldConfig in protobuf, but it was too time
consuming. The loosely defined Formly json data API creates significant
friction when joined with a well defined protobuf API. Therefore, we do
not specify anything about the Forms API, convey any valid JSON, and
leave it up to CUE and Formly on the sending and receiving side of the
API.
We use CUE to define our own holos form elements as a subset of the loose
Formly definitions. We further hope Formly will move toward a better JSON
data API, but it's unlikely. Consider replacing Formly entirely and
building on top of the strongly typed Angular Dyanmic Forms API.
This patch wires up a Select and a Multi Select box. This patch also establishes a decision as it relates to Formly TypeScript / gRPC Proto3 / CUE definitions of the form data structure. The decision is to use gRPC as a transport for any JSON to avoid friction trying to fit Formly types into Proto3 messages.
Note when using google.protobuf.Value messages with bufbuild/connect-es, we need to round trip them one last time through JSON to get the original JSON on the other side. This is because connect-es preserves the type discriminators in the case and value fields of the message.
Refer to: Accessing oneof groups
NOTE: On the wire, carry any JSON as field configs for expedience. I attempted to reflect FormlyFieldConfig in protobuf, but it was too time consuming. The loosely defined Formly json data API creates significant friction when joined with a well defined protobuf API. Therefore, we do not specify anything about the Forms API, convey any valid JSON, and leave it up to CUE and Formly on the sending and receiving side of the API.
We use CUE to define our own holos form elements as a subset of the loose Formly definitions. We further hope Formly will move toward a better JSON data API, but it's unlikely. Consider replacing Formly entirely and building on top of the strongly typed Angular Dyanmic Forms API.
Refer to: https://github.com/ngx-formly/ngx-formly/blob/v6.3.0/src/core/src/lib/models/fieldconfig.ts#L15 Consider: https://angular.io/guide/dynamic-form
Usage:
Generate the form from CUE
Store the form JSON in the config_values column of the platforms table.
View the form, and submit some data. Then get the data back out for use rendering the platform: