-
Notifications
You must be signed in to change notification settings - Fork 163
Connectors JSON Schema #8632
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Connectors JSON Schema #8632
Conversation
274c8cd to
45c3e9f
Compare
|
bug: nit: Are we not going to add HTTPS connector as two step in this PR? fine to do in in another, but we're already here so might as well. Seeing we removed clickhosue specific forms, can we also split clickhouse-cloud and clickhouse into separate .ts? |
royendo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see above :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good progress on migrating connectors to JSON Schema. The schema files are well-structured and the JSONSchemaFormRenderer is now generic. However, there are architectural concerns that should be addressed to fully realize the vision from PR #8467.
ClickHouse is not using the JSON Schema system
ClickhouseFormRenderer.svelte renders fields by iterating over clickhouseUiState?.filteredProperties, which originates from the backend's configProperties:
// ClickhouseFormRenderer.svelte:61
{#each clickhouseUiState?.filteredProperties ?? [] as property (property.key)}
...
{#if property.type === ConnectorDriverPropertyType.TYPE_STRING ...}This means ClickHouse has a JSON Schema (schemas/clickhouse.ts) that's only used for validation, not rendering. The form structure still comes from the backend.
The unique ClickHouse patterns—connector type selector, Parameters/DSN tabs, conditional SSL/port behavior—should be modeled as JSON Schema extensions so JSONSchemaFormRenderer can render them:
- The connector type selector is already a radio enum pattern (
x-display: "radio") - Parameters/DSN tabs could use
x-display: "tabs"orx-input-mode(per the migration path in #8467) - Conditional field behavior already works via
allOf/if/then
Once modeled in the schema, ClickhouseFormRenderer.svelte can be deleted and ClickHouse can flow through the same path as other connectors.
Frontend still consumes backend configProperties/sourceProperties
The design doc vision was for JSON Schema to be the single source of truth. Currently, backend properties are still consumed in multiple places:
-
FormRenderer.svelte- renders entirely fromConnectorDriverProperty[] -
AddDataFormManager.ts:164-191, 430-441- derives properties, DSN detection, initial values -
MultiStepConnectorFlow.svelte:59-60, 77- usessourceProperties/configPropertiesfor initialization -
sourceUtils.ts:229-242- iterates over properties for form data preparation
For connectors with JSON Schemas, the schema should drive everything: field structure, labels, placeholders, hints, and validation. Backend properties should only be a fallback during migration.
What "done" looks like
Before we consider the JSON Schema migration complete, we need:
-
Tabs support in
JSONSchemaFormRenderer- Model the Parameters/DSN pattern as a schema extension (e.g.,x-display: "tabs"withx-tab-group). This unblocks ClickHouse and other connectors with dual input modes. -
ClickHouse rendering through
JSONSchemaFormRenderer- DeleteClickhouseFormRenderer.svelteonce the schema can express all its UI patterns. -
Schema-driven connectors stop reading
configProperties/sourceProperties- Derive field metadata from the schema. This may require enriching schemas withx-placeholder,x-hint, etc. where they're currently missing.
Without these, we have two parallel rendering systems that must be maintained independently.
Developed in collaboration with Claude Code
This reverts commit 93bfc90.




This PR refactors all connector forms to use a unified JSON schema-based validation and rendering system, replacing the previous Yup-based validation approach.
Checklist: