feat!: json schemas for device config and mappings #837
Conversation
|
⚡ Published prerelease version shared-lib@1.49.0-nightly-feat-gateways-json-schema-20230307-151520-56499b3.0 to NPM |
|
One note I'd like to make on this PR is that it definitely breaks compatibility with any Peripheral Devices, so I would like to hold off on merging this in until we have a wider discussion on how to handle that, by for example bumping Core (and Playout Gateway, MOS Gateway, and Package Manager and Input Gateway) to 2.0.0 |
| return ( | ||
| <> | ||
| {' '} | ||
| {Object.entries(props.schema.properties || {}).map(([index, schema]) => { |
There was a problem hiding this comment.
Shouldn't this also take additionalProperties into consideration? I'm looking into how this affects Input Gateway, and have one instance where for one of the SubDevice types, I want to have a configuration of an object type, with user-configurable keys that then contains an object definition for that key that varies on a type discriminator property. In that case I used a ConfigManifestEntryType.TABLE with a defaultType, typeField and some config type definitions. I don't think this is possible here?
There was a problem hiding this comment.
I dont think additionalProperties is something the UI should be looking at. https://json-schema.org/understanding-json-schema/reference/object.html#additional-properties
The best we would be able to do if using it is allow for adding custom fields, using additionalProperties and patternProperties to limit the names/types of those. But they wont have a description or anything, so that wont be a good replication of what you were doing in input gateway.
I forgot to check input-gateway, so didn't realise that complex use of nested tables was being used. It could either be reimplemented using oneOf, or that table could be split up into multiple tables to not need the complex types
There was a problem hiding this comment.
Yeah, I guess we can live with a multiple tables, I don't expect us to configure the MIDI integration all that often. Although I think we should leave some TODO here, since this is quite a significant limitation, I think.
|
This is now ready to be merged into Release 50 branch. |
feature for R50
Depends on nrkno/sofie-timeline-state-resolver#237
Gateways use a custom format for defining the config ui.
For TSR, this information is defined in playout-gateway, causing differences to occur between the manifest and the types in TSR.
Building on #809, this changes gateways to use a json-schema to define their configuration. It is expected that typescript interfaces should be generated from this schema to ensure that it stays in sync too.
Support for the old ConfigManifest has been removed for the gateways, but the blueprint variant is still in use for blueprint based things currently. That should be expected to change in a future PR.
Ill admit that the
SchemaForm*types are a little strange in how they are built onSchemaFormWithOverrides. After doing the initial step of device config with a basicSchemaFormtype, I found that for Mappings which use theObjectWithOverridesstructure, it was necessary for a variation of the SchemaForm which supported this (including a variation of the table type). While implementing this I realised that aSchemaFormWithOverrideswith no default values would behave the same as the basicSchemaFormtype, so to avoid duplication and similar types which would drift apart in functionality over time I wrote theSchemaFormForCollectionas a way of achieving this.SchemaFormForCollectionturned out simpler than I hoped, so I am pretty happy with the result.Status