feat(schema-form): add basic JSON schema parser utility

[ShreyasGhodke]

Why submit this pull request?

• Bugfix
• New feature provided
• Improve performance
• Backport patches

What changes will this PR take into?

This PR introduces a basic utility to parse JSON Schema definitions
into a structure suitable for rendering dynamic configuration forms
in the APISIX Dashboard.

The parser extracts:

• schema property names
• property types
• required fields
• enum options
• default values

This can be used as a foundation for implementing a reusable SchemaForm
component that renders plugin configuration forms directly from JSON Schema.

Related issues

N/A

Checklist:

• Did you explain what problem does this PR solve? Or what new features have been added?
• Have you added corresponding test cases?
• Have you modified the corresponding document?
• Is this PR backward compatible? If it is not backward compatible, please discuss on the mailing list first

[ShreyasGhodke]

Hi maintainers,

I’m exploring contributions around schema-driven plugin configuration forms for the dashboard. This PR adds a small utility that parses JSON Schema properties into a structure that can later be used for dynamic form rendering.

I’d really appreciate any feedback or suggestions for improving this approach.

Thank you!
-SG

[Baoyuantop]

Hi @ShreyasGhodke, thank you for your contribution. Since this is just a utility function, I suggest marking the PR as a draft for now. A single function doesn’t tell us much on its own, so please flesh out your technical proposal further.

[ShreyasGhodke]

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