GSoC 2026 Proposal: JSON Schema Driven Form Component [APISIX-39]

[DSingh0304]

GSoC 2026 Proposal: JSON Schema Driven Form Component [APISIX-39]

1. Project Information

• Project Name: JSON Schema to Form UI for APISIX Dashboard (APISIX-39)
• Student Name: Deep Shekhar Singh
• GitHub: @DSingh0304
• Timezone: IST (UTC+5:30)

---

2. Why I am the Right Candidate for this Project

Over the past few months, I have become deeply involved in the APISIX Dashboard codebase, significantly improving its stability and test coverage. I am intimately familiar with its React 19 + Mantine + react-hook-form architecture.

My Key Core Contributions:

1. Massive E2E Test Suite Expansion (10+ Merged PRs): Authored comprehensive E2E tests for Services (test(e2e): add comprehensive service CRUD tests and UI utility functions #3258), Stream Routes (test: add stream route E2E tests with detail page flows #3255), Consumer Groups (test: add E2E tests for Consumer Groups #3250), SSLs (test: add E2E tests for SSLs (#3087) #3249), Global Rules (test: add E2E tests for global rules #3248), Plugin Metadata (test: add E2E tests for plugin metadata resource #3247), Plugin Configs (test: add comprehensive E2E tests for plugin configs #3246), Secrets (test: add comprehensive E2E tests for Secrets resource #3245), Protos (test: add E2E tests for protos #3244), and Consumers (test(e2e): Add E2E tests for consumer and credentials #3243).
2. UI Crash Resolution: Resolved UI crashes caused by vars form component array formatting via a.trim() tags input (fix: a.trim is not a function #3286).
3. Advanced Search Implementation: Developed the hybrid routing search form with 9 frontend/backend filter fields (feat: add route search form with 9 filter fields #3222).
4. CI Pipeline Improvement: Implemented the strict CI Linting workflow (feat: add lint workflow #3291).

---

3. Working Proof of Concept: PR #3274 (Already Validated)

I have already built a high-coverage Proof of Concept (#3274) that demonstrates the project's viability natively within the dashboard. The maintainer (@Baoyuantop) has validated this approach, and the PR serves as a concrete foundation for the GSoC term.

Current PoC Highlights (as of March 2026):

• 50 Passing Integration Tests: Verified via Vitest + JSDOM, covering recursion, widget mapping, and complex conditional logic.
• 🧼 High-Priority Correctness: Implemented automatic Form State Cleanup using unregister(). When users switch between oneOf or anyOf branches, stale/ghost values are instantly purged. This ensures "Submit Payload Consistency"a critical requirement for the APISIX Admin API.
• Zero-Warning Build: Compliant with strict project linting (--max-warnings=0).

(Below is a screen recording of the working SchemaForm PoC generating the UI and demonstrating real-time form state cleanup/payload consistency)

Screencast.from.2026-03-24.18-14-13.mp4

---

4. Project Description & Approach

The Problem:
Currently, configuring APISIX plugins requires writing raw JSON in a Monaco editor. With 150+ plugins, each with unique schema definitions, maintaining hand-coded forms is unsustainable and prone to user error.

The Solution & Approach:
The Admin API already exposes full JSON Schema at GET /apisix/admin/schema/plugins/{name}. My approach dynamically auto-generates user-friendly forms directly from these schemas using:

• React Hook Form (RHF): For performant, un-controlled form state management.
• AJV: For formal validation, bridging errors to react-hook-form setError.
• Mantine UI 8: Reusing existing widgets from src/components/form/ for a native look.

The Integration Strategy (The "Toggle" Approach):
I propose integrating the SchemaForm into PluginEditorDrawer with a toggle switch. Users see the auto-generated UI form by default, but can toggle back to the Monaco JSON editor for fine-grained control or unrecognized schema portions. This guarantees zero regressions.

---

5. Deliverables & Implementation Phases

Must-have (Phase 1: Completed in PoC/Early GSoC)

1. Reusable SchemaForm component supporting basic objects and recursive nesting.
2. Widget mapping for basic types (string, number, boolean, enum, array).
3. Conditional Rendering: Full support for oneOf, anyOf, and dependencies.
4. Advanced Logic: if/then/else sub-schema rendering via AJV evaluation.
5. Form State Cleanup: Automatic unregister() of deselected branches for payload consistency.
6. APISIX Extensions: Handling encrypt_fields (PasswordInput) and patternProperties (Dynamic Maps).

Should-have (Phase 2: Mid GSoC)

1. Full PluginEditorDrawer integration with Toggle Fallback logic.
2. Smart Label Formatting (Acronym handling for OAuth, API, ID, etc.).
3. Detailed error mapping for nested field paths.
4. Comprehensive Unit & E2E Testing (Playwright).

Nice-to-have (Phase 3: End of GSoC)

1. allOf merging support.
2. $ref / $defs resolution for recursive schemas.
3. Read-only mode for viewing existing configuration.

---

6. APISIX Plugin Schema Patterns Supported

My current PoC already supports patterns found in the most critical APISIX plugins:

• limit-conn, limit-count (oneOf, anyOf, if/then/else)
• jwt-auth, key-auth (encrypt_fields)
• proxy-rewrite (patternProperties, nested objects)
• traffic-split (complex arrays of objects)

---

7. Related Resources

• Admin API schema endpoint: apisix/admin/plugins.lua
• Core schemas: apisix/schema_def.lua
• Dashboard technical design: Technical Design of the New Dashboard #2988

---

8. Other Commitments

• I am fully committed to completing this project. I have no other internships or full-time jobs planned for this summer.

[DSingh0304]

Hi @Baoyuantop, following your suggestion on the mailing list regarding GSoC 2026 applications, I have formalized my proposal for APISIX-39 here. It includes the technical approach for the SchemaForm component and references my ongoing work in PR #3274. I’m looking forward to any feedback or suggestions from you and the community!

[toalone567-art]

GSoC 2026 Proposal: JSON Schema Driven Form Component [APISIX-39]

1. Project Information

• Project Name: JSON Schema to Form UI for APISIX Dashboard (APISIX-39)
• Student Name: Deep Shekhar Singh
• GitHub: @DSingh0304
• Timezone: IST (UTC+5:30)

2. Why I am the Right Candidate for this Project

Over the past few months, I have become deeply involved in the APISIX Dashboard codebase, significantly improving its stability and test coverage. I am intimately familiar with its React 19 + Mantine + react-hook-form architecture.

My Key Core Contributions:

1. Massive E2E Test Suite Expansion (10+ Merged PRs): Authored comprehensive E2E tests for almost every major resource, including Services (test(e2e): add comprehensive service CRUD tests and UI utility functions #3258), Stream Routes (test: add stream route E2E tests with detail page flows #3255), Consumer Groups (test: add E2E tests for Consumer Groups #3250), SSLs (test: add E2E tests for SSLs (#3087) #3249), Global Rules (test: add E2E tests for global rules #3248), Plugin Metadata (test: add E2E tests for plugin metadata resource #3247), Plugin Configs (test: add comprehensive E2E tests for plugin configs #3246), Secrets (test: add comprehensive E2E tests for Secrets resource #3245), Protos (test: add E2E tests for protos #3244), and Consumers (test(e2e): Add E2E tests for consumer and credentials #3243).
2. UI Crash Resolution: Resolved UI crashes caused by vars form component array formatting via a.trim() tags input (fix: a.trim is not a function #3286).
3. Advanced Search Implementation: Developed the hybrid routing search form with 9 frontend/backend filter fields (feat: add route search form with 9 filter fields #3222).
4. CI Pipeline Improvement: Implemented the strict CI Linting workflow (feat: add lint workflow #3291).

3. Working Proof of Concept (Submitted in January, PR #3274)

I didn't want to just propose an idea; I wanted to prove it works natively within the dashboard. In early January, I submitted an initial Proof of Concept that addressed the core concerns in the original feature request (#2986). The maintainer (@Baoyuantop) validated this approach and the corresponding PR #3274.

(Below is a screen recording of the working SchemaForm PoC generating the UI for the proxy-rewrite plugin directly from its JSON Schema)

Screencast.from.2026-03-03.20-30-24.mp4
Since that initial validation, the PoC has been extended and currently successfully implements rendering of basic types, oneOf, dependencies, and dynamic array handling without external libraries (using RHF's useFieldArray and Mantine's TagsInput), all wrapped in an AJV validation pipeline with zero new heavy external dependencies.

4. Project Description & Approach

The Problem: Currently, configuring APISIX plugins in the Dashboard requires writing raw JSON in a Monaco editor within PluginEditorDrawer. With over 150+ plugins, each with unique schema definitions, maintaining hand-coded forms is unsustainable. Relying on raw JSON leads to a steep learning curve, validation errors, and a poor developer experience.

The Solution & Approach: The Admin API already exposes full JSON Schema at GET /apisix/admin/schema/plugins/{name}. We can dynamically auto-generate user-friendly forms directly from these schemas. Instead of relying on heavy third-party JSON-to-Form libraries that are hard to customize, my approach builds exactly upon the Technical Design outlined in #2988:

• React Hook Form (RHF): For performant, un-controlled form state management.
• AJV: For deterministic validation, bridging errors to react-hook-form setError.
• Mantine UI 8: Reusing existing widgets from src/components/form/.

The Integration Strategy (The "Toggle" Approach): Replacing a working JSON editor carries a risk if a complex plugin schema has unsupported edge cases. I propose integrating the SchemaForm into PluginEditorDrawer with a toggle switch. Users see the auto-generated UI form by default, but can toggle back to the raw JSON Monaco editor for unrecognized/complex schema portions. This guarantees zero regressions.

5. Deliverables & Implementation Phases

Must-have (Phase 1 - Early/Mid GSoC)

1. Reusable SchemaForm component that accepts a JSON Schema object and renders a complete form.
2. Widget mapping for basic types: string → TextInput, number/integer → NumberInput, boolean → Switch, object → nested fieldset, array → repeatable field group (useFieldArray).
3. enum support mapping to Select dropdown.
4. Support for default values and required field enforcement.
5. Basic constraints: minimum/maximum, minLength/maxLength, pattern, exclusiveMinimum, minItems/maxItems.
6. oneOf support (selector to choose a variant, render corresponding fields).
7. dependencies / conditional fields (show/hide fields based on other field values).
8. if/then/else conditional sub-schema rendering.
9. Validation via AJV against the original JSON Schema, mapping errors inline.
10. encrypt_fields meta handling (rendering as PasswordInput).

Should-have (Phase 2 - Mid/Late GSoC)

1. Full PluginEditorDrawer integration with Toggle Fallback logic between SchemaForm and Monaco JSON editor.
2. anyOf support.
3. patternProperties support (dynamic key-value editor).
4. Schema-to-widget override registry (e.g., x-widget standard for custom widgets).
5. Comprehensive Unit & E2E Testing (Playwright).

Nice-to-have (Phase 3 - End of GSoC / Post-GSoC)

1. allOf merging.
2. $ref / $defs resolution.
3. Read-only/disabled mode for viewing existing config.

6. APISIX Plugin Schema Patterns to Support

Pattern Example Plugins Utilizing Pattern
oneOf limit-conn, limit-count, jwt-auth, response-rewrite
dependencies limit-conn, jwt-auth
if/then/else response-rewrite, limit-conn, openid-connect, ai-proxy
anyOf Core schema_def.lua, ai-proxy-multi
patternProperties ai-proxy, labels_def
Arrays & Objects traffic-split

7. Related Resources

• Admin API schema endpoint: apisix/admin/plugins.lua
• Core schemas: apisix/schema_def.lua
• Dashboard technical design: Technical Design of the New Dashboard #2988

(cc @Baoyuantop @juzhiyuan @nic-chen @LiteSun @liuxiran @bzp2010)

8. Other Commitments

• I am fully committed to completing this project. I have no other internships or full-time jobs planned for this summer.

[Jaswanth-arjun]

Hi @DSingh0304 , I reviewed the proposal and PR #3274.

The SchemaForm implementation looks quite comprehensive.
I would like to contribute by helping extend and improve it.

Possible areas I can work on:

• Improving UI/UX of generated forms
• Adding support for remaining schema patterns like anyOf / patternProperties
• Writing unit and integration tests
• Enhancing documentation for schema-to-widget mapping

Please let me know if this would be helpful, or suggest areas where contributions are needed.

[DSingh0304]

Hi @DSingh0304 , I reviewed the proposal and PR #3274.

The SchemaForm implementation looks quite comprehensive.
I would like to contribute by helping extend and improve it.

Possible areas I can work on:

• Improving UI/UX of generated forms
• Adding support for remaining schema patterns like anyOf / patternProperties
• Writing unit and integration tests
• Enhancing documentation for schema-to-widget mapping

Please let me know if this would be helpful, or suggest areas where contributions are needed.

Hi @Jaswanth-arjun thank you for your review, but I am still working on the PR and improving it myself, you can suggest the changes in the comments here I will try to integrate those of possible!!

[Jaswanth-arjun]

Hi @DSingh0304,

Great improvement on the SchemaForm flow — the stale field cleanup fix makes the conditional behavior much more reliable and aligns well with react-hook-form expectations.

I tested the demo locally, and it works well overall. I had a few suggestions that might help strengthen it further:

1. Repeated branch switching
   It might be useful to stress-test rapid toggling (A → B → A → B) to ensure no stale values or validation errors persist across inactive branches.

2. Nested field cleanup
   For deeply nested objects or arrays, we should ensure unregistering a parent path consistently removes the full subtree from form state.

3. useWatch optimization
   Since conditional rendering relies on useWatch, we could consider narrowing subscriptions to only relevant fields (like discriminators) and memoizing branch resolution logic to reduce unnecessary re-renders.

4. Additional test coverage
   It may help to add tests for:

• repeated branch switching
• nested object/array cleanup
• switching branches with existing validation errors

Happy to help contribute to any of these if needed. Let me know your thoughts!

[DSingh0304]

Hi @DSingh0304,

Great improvement on the SchemaForm flow — the stale field cleanup fix makes the conditional behavior much more reliable and aligns well with react-hook-form expectations.

I tested the demo locally, and it works well overall. I had a few suggestions that might help strengthen it further:

1. Repeated branch switching
   It might be useful to stress-test rapid toggling (A → B → A → B) to ensure no stale values or validation errors persist across inactive branches.

2. Nested field cleanup
   For deeply nested objects or arrays, we should ensure unregistering a parent path consistently removes the full subtree from form state.

3. useWatch optimization
   Since conditional rendering relies on useWatch, we could consider narrowing subscriptions to only relevant fields (like discriminators) and memoizing branch resolution logic to reduce unnecessary re-renders.

4. Additional test coverage
   It may help to add tests for:


* repeated branch switching

* nested object/array cleanup

* switching branches with existing validation errors

Happy to help contribute to any of these if needed. Let me know your thoughts!

Sure I will look into these..