ShreyasGhodke commented on PR #3328:
URL:
https://github.com/apache/apisix-dashboard/pull/3328#issuecomment-4068132927
Hi @Baoyuantop
I’ve converted the PR to draft and expanded the idea below to clarify how
this utility fits into a broader schema-driven form system for the dashboard.
## Background / Problem
Many plugins in Apache APISIX already define their configuration using JSON
Schema. However, in the dashboard UI, plugin configuration forms are often
created manually. This means:
* Form fields must be maintained separately from the plugin schema.
* When plugin schemas change, UI forms may become outdated.
* Adding support for new plugins may require additional UI development.
Since the plugin schemas already contain structured metadata about
configuration parameters, it may be possible for the dashboard to use that
schema to dynamically generate configuration forms.
## Goal
The goal of this work is to explore a schema-driven approach where the
dashboard can automatically generate plugin configuration forms from plugin
JSON schemas.
This would allow:
* Faster support for new plugins
* Reduced manual UI maintenance
* Better alignment between plugin schemas and dashboard configuration forms
The utility function introduced in this PR is intended as an early step
toward parsing JSON Schema properties into a format that the frontend can later
use for dynamic form rendering.
## Proposed Architecture
The high-level idea is to introduce a translation layer that converts plugin
JSON schemas into a form-friendly structure.
Conceptual flow:
APISIX Plugin Schema
↓
Schema Parser Utility
↓
Intermediate Form Schema
↓
SchemaForm Component
↓
Dynamic Plugin Configuration UI
### 1. Schema Parser Utility
The utility introduced in this PR focuses on parsing JSON Schema properties
and extracting key attributes such as:
* field name
* type
* default value
* required status
* enum values
* description
This parsed structure can then be used by the UI to determine which form
components should be rendered.
### 2. Intermediate Form Schema
Instead of using raw JSON schema directly in the UI, the parser would
generate a simplified intermediate structure. For example:
**Example JSON Schema:**
{
"type": "object",
"properties": {
"timeout": {
"type": "integer",
"default": 3,
"description": "request
timeout"
},
"enable": {
"type": "boolean"
}
}
}
**Parsed structure:**
[
{
"name": "timeout",
"component": "InputNumber",
"default": 3,
"description": "request timeout"
},
{
"name": "enable",
"component": "Switch"
}
]
_This structure would make it easier for the frontend to render dynamic
forms._
### 3. SchemaForm Component
In the next stage, a reusable SchemaForm component could be introduced in
the dashboard UI that takes the parsed schema and renders form components
dynamically.
Example mapping could include:
* string → text input
* integer → number input
* boolean → switch
* enum → select dropdown
* array → dynamic list
### 4. Plugin Configuration Integration
Once the schema parser and SchemaForm component are in place, the plugin
configuration page could load the plugin schema and dynamically render the form
fields.
This would allow plugin configuration forms to adapt automatically when
schemas evolve.
## Potential Benefits
* Reduced manual maintenance of plugin configuration forms
* Faster UI support for newly added plugins
* Consistency between backend schema definitions and frontend configuration
UI
* More scalable plugin management in the dashboard
## Future Work
If this direction aligns with the project goals, possible next steps could
include:
1. Improving the schema parsing logic to support more JSON Schema constructs
2. Designing the intermediate form schema format
3. Implementing the SchemaForm UI component
4. Integrating schema-driven rendering into the plugin configuration page
5. Supporting validation rules derived from plugin schemas
## Feedback
Since I’m still exploring the dashboard architecture, I would appreciate
feedback from maintainers on whether this schema-driven approach would align
with the long-term direction of the dashboard.
If this direction makes sense, I can continue refining the parser utility
and gradually move toward integrating it with the UI components.
Thank you for the guidance!
-SG
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
