Re: [I] feat: JSON Schema-driven UI for APISIX Plugin Configuration [GSoC 2026 Proposal] [apisix-dashboard]

2026-03-28 Thread via GitHub


Baluduvamsi2006 commented on issue #3347:
URL: 
https://github.com/apache/apisix-dashboard/issues/3347#issuecomment-4148630809

   Hi @Baoyuantop ,
   
   Thank you for the guidance. I have updated this proposal to align with #3274 
and I will avoid building a parallel SchemaForm engine.
   
   ## Alignment plan
   
   ### 1) What I will reuse from #3274
   - Existing SchemaForm foundation and recursive rendering direction
   - Current conditional rendering baseline (oneOf/anyOf/if-then-else)
   - Existing AJV + test/demo baseline where applicable
   
   ### 2) What I will add/improve
   - Correctness hardening first:
 - branch-switch cleanup
 - payload consistency (no inactive-branch leakage)
 - deterministic conditional behavior
   - Edge-case reliability tests:
 - nested branch transitions
 - repeated switching
 - dependencies interactions
   - Incremental production integration polish for selected plugin flows
   - Contributor-facing docs for schema-to-widget extension and debugging
   
   ### 3) MVP gates (verifiable per phase)
   For each phase I will provide:
   - reproducible demo scenario
   - explicit test additions
   - pass criteria
   
   Quality bar:
   - tests pass
   - lint clean
   - no stale inactive-branch values in submit payload for covered scenarios
   
   I will keep this issue as the tracking/alignment issue and continue with 
small, reviewable PR slices based on this plan.  
   Thanks again for the review direction.


-- 
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]



Re: [I] feat: JSON Schema-driven UI for APISIX Plugin Configuration [GSoC 2026 Proposal] [apisix-dashboard]

2026-03-25 Thread via GitHub


Jaswanth-arjun commented on issue #3347:
URL: 
https://github.com/apache/apisix-dashboard/issues/3347#issuecomment-4124287426

   Hi @Baoyuantop, @DSingh0304, @Baluduvamsi2006,
   
   Thanks for the detailed discussion and alignment around #3274.
   
   From reviewing the thread, I understand that the focus is now on extending 
and stabilizing the existing SchemaForm implementation rather than creating a 
separate solution.
   
   As a beginner contributor, I would like to support this effort in smaller, 
focused areas such as:
   
   - Writing additional test cases for edge cases (e.g., repeated branch 
switching, nested cleanup)
   - Improving UI/UX consistency of generated forms
   - Assisting with documentation for schema-to-widget mapping
   
   Please let me know if contributions in these areas would be helpful, or if 
there are specific smaller tasks I can take up.
   
   Thanks!


-- 
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]



Re: [I] feat: JSON Schema-driven UI for APISIX Plugin Configuration [GSoC 2026 Proposal] [apisix-dashboard]

2026-03-24 Thread via GitHub


DSingh0304 commented on issue #3347:
URL: 
https://github.com/apache/apisix-dashboard/issues/3347#issuecomment-4117905528

   > Thanks for the detailed proposal and PoC 
([#3346](https://github.com/apache/apisix-dashboard/pull/3346)). The phased 
breakdown and acceptance criteria are well-structured, which is helpful for 
GSoC evaluation.
   > 
   > This direction is valuable. However, there's already a related PoC in 
[#3274](https://github.com/apache/apisix-dashboard/pull/3274) with deeper 
coverage (anyOf, if/then/else, encrypt_fields + 43 tests).
   > 
   > To avoid duplicate efforts, I'd suggest focusing on:
   > 
   > 1. Clarify how your approach aligns with / reuses [GSOC 26 Proof of 
Concept: add SchemaForm component for JSON Schema to Form UI 
#3274](https://github.com/apache/apisix-dashboard/pull/3274), rather than 
building two parallel engines
   > 
   > 2. Prioritize correctness issues first (especially form state cleanup 
on branch switching, submit payload consistency)
   > 
   > 3. Bind each phase to verifiable deliverables (test cases + 
reproducible demo + pass criteria)
   > 
   > 
   > If you're interested, consider posting an "alignment plan" in this issue:
   > 
   > * Which parts of [GSOC 26 Proof of Concept: add SchemaForm component 
for JSON Schema to Form UI 
#3274](https://github.com/apache/apisix-dashboard/pull/3274) you plan to reuse
   > 
   > * Which capabilities/tests you'll add
   > 
   > * Minimum mergeable target (MVP gate) for each phase
   > 
   > 
   > This would make the proposal more compelling in the GSoC context.
   
   Hi @Baoyuantop ,
   
   Regarding your points on correctness and alignment, I have just pushed a 
major update to #3274 that directly addresses the "Form State Cleanup" priority 
you mentioned:
   
   ###  1. Alignment on Correctness (Form State Cleanup)
   I have implemented a robust state management system using `unregister()` 
within the recursive `SchemaField` dispatcher.
   *   **The Fix:** When a user switches branches (e.g., in a `oneOf` or 
`anyOf` selection), all stale/ghost values from the non-active branches are now 
automatically removed from the form state.
   *   **Submit Payload Consistency:** This ensures that the final payload sent 
to the APISIX backend strictly adheres to the schema of the **currently 
selected** plugin variant, preventing hidden validation errors from inactive 
fields.
   
   ###  2. Verifiable Deliverables
   I’ve updated my proposal to bind each phase to these deliverables:
   *   **Test Suite:** Expanded to **47 passing tests** (vitest) covering 
conditional branch switching and recursive validation.
   *   **Live Demo:** Updated the `schema_form_demo` route with a "Live Form 
Data" monitor, allowing maintainers to visually verify that the payload is 
cleaned up in real-time as they toggle options.
   *   **Pass Criteria:** 100% test pass rate + zero-warning `pnpm lint` build 
(verified with `--max-warnings=0`).
   
   
   I believe #3274 now serves as a solid unified engine for the dashboard. I 
look forward to your thoughts on this updated direction!
   
   
   


-- 
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]



Re: [I] feat: JSON Schema-driven UI for APISIX Plugin Configuration [GSoC 2026 Proposal] [apisix-dashboard]

2026-03-24 Thread via GitHub


DSingh0304 commented on issue #3347:
URL: 
https://github.com/apache/apisix-dashboard/issues/3347#issuecomment-4117310370

   > Thanks for the detailed proposal and PoC 
([#3346](https://github.com/apache/apisix-dashboard/pull/3346)). The phased 
breakdown and acceptance criteria are well-structured, which is helpful for 
GSoC evaluation.
   > 
   > This direction is valuable. However, there's already a related PoC in 
[#3274](https://github.com/apache/apisix-dashboard/pull/3274) with deeper 
coverage (anyOf, if/then/else, encrypt_fields + 43 tests).
   > 
   > To avoid duplicate efforts, I'd suggest focusing on:
   > 
   > 1. Clarify how your approach aligns with / reuses [GSOC 26 Proof of 
Concept: add SchemaForm component for JSON Schema to Form UI 
#3274](https://github.com/apache/apisix-dashboard/pull/3274), rather than 
building two parallel engines
   > 
   > 2. Prioritize correctness issues first (especially form state cleanup 
on branch switching, submit payload consistency)
   > 
   > 3. Bind each phase to verifiable deliverables (test cases + 
reproducible demo + pass criteria)
   > 
   > 
   > If you're interested, consider posting an "alignment plan" in this issue:
   > 
   > * Which parts of [GSOC 26 Proof of Concept: add SchemaForm component 
for JSON Schema to Form UI 
#3274](https://github.com/apache/apisix-dashboard/pull/3274) you plan to reuse
   > 
   > * Which capabilities/tests you'll add
   > 
   > * Minimum mergeable target (MVP gate) for each phase
   > 
   > 
   > This would make the proposal more compelling in the GSoC context.
   
   Thanks for the ping! I'm the author of #3274. Happy to collaborate and 
discuss where the implementations can align. The core engine is intentionally 
designed to be extensible. Feel free to open a discussion on that PR.


-- 
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]



Re: [I] feat: JSON Schema-driven UI for APISIX Plugin Configuration [GSoC 2026 Proposal] [apisix-dashboard]

2026-03-23 Thread via GitHub


ShreyasGhodke commented on issue #3347:
URL: 
https://github.com/apache/apisix-dashboard/issues/3347#issuecomment-4109820268

   ## Feature request
   
   ### Please describe your feature
   
   Plugin configuration in Apache APISIX Dashboard is currently edited 
primarily as raw JSON.
   While flexible, this approach increases cognitive load, especially for new 
users, and can lead to invalid configurations due to schema unfamiliarity.
   
   Since APISIX plugins already provide JSON Schema definitions, the dashboard 
can leverage this to provide a schema-driven configuration UI.
   
   ---
   
   ### Describe the solution you'd like
   
   I propose building a **reusable, schema-driven form engine** for plugin 
configuration by **extending and aligning with the existing PoC (#3274)** 
rather than introducing a parallel implementation.
   
   The goal is to deliver a **progressively enhanced SchemaForm system** that:
   
   * reuses the existing SchemaForm foundation (#3274)
   * improves correctness and stability
   * incrementally adds missing capabilities required for production use
   
   ---
   
   ## Core Design Approach
   
   ### 1. Schema Integration Layer
   
   * Reuse schema parsing logic from #3274 where available
   * Normalize plugin schema into a consistent internal structure
   * Handle:
   
 * nested objects
 * default values
 * required fields
   
   Focus: **stability and correctness over reimplementation**
   
   ---
   
   ### 2. Field Rendering Layer
   
   Extend existing component mappings:
   
   * string → input / textarea
   * number/integer → numeric input
   * boolean → switch
   * enum → select / radio
   * object → nested sections
   * array → dynamic list editor
   
   Enhancements:
   
   * better label/description extraction
   * improved layout consistency
   * support for default value hydration
   
   ---
   
   ### 3. Conditional Rendering (Focused Improvement)
   
   Instead of rebuilding logic, improve correctness of existing patterns:
   
   * fix branch switching inconsistencies
   * ensure inactive branches:
   
 * do not leak values into submission
 * properly clean up form state
   
   Supported:
   
   * if / then / else (priority)
   * oneOf / anyOf (incremental support)
   
   ---
   
   ### 4. Validation Layer
   
   * Integrate AJV for schema validation
   * Normalize validation errors into:
   
 * field-level messages
 * form-level summary
   
   Focus:
   
   * accurate error mapping to field paths
   * preventing invalid submissions
   
   ---
   
   ### 5. Form ↔ JSON Sync Layer
   
   * Maintain two modes:
   
 * Schema Form Mode
 * Raw JSON Mode
   * Ensure:
   
 * no data loss during switching
 * consistent serialization/deserialization
   
   ---
   
   ## Implementation Plan
   
   ### Phase 1 — MVP Stabilization (High Priority)
   
   Focus on improving and extending #3274:
   
   * reuse SchemaForm base
   * implement:
   
 * primitive + object rendering
 * enum support
 * required fields
 * default values
   * fix:
   
 * inconsistent form state behavior
   
   **Deliverables:**
   
   * stable SchemaForm MVP
   * unit tests for schema parsing + rendering
   * demo with real plugin schemas
   
   ---
   
   ### Phase 2 — Conditional Logic (Correctness First)
   
   * improve if/then/else handling
   * fix branch switching issues:
   
 * stale values
 * incorrect payload submission
   
   **Deliverables:**
   
   * deterministic conditional rendering
   * tests for branch transitions
   * reproducible edge case scenarios
   
   ---
   
   ### Phase 3 — Validation + UX
   
   * integrate AJV validation
   * map errors to UI fields
   * improve UX:
   
 * inline errors
 * section highlighting
   
   **Deliverables:**
   
   * full validation pipeline
   * user-friendly error display
   * regression tests
   
   ---
   
   ### Phase 4 — Hardening + Coverage
   
   * test with multiple real plugin schemas
   * optimize rendering for nested schemas
   * improve documentation for contributors
   
   **Deliverables:**
   
   * production-ready behavior
   * developer guide for schema mapping
   * test coverage for critical flows
   
   ---
   
   ## Alignment with Existing Work
   
   This proposal **builds directly on GSOC PoC #3274** by:
   
   * reusing its SchemaForm foundation
   * improving correctness instead of duplicating logic
   * extending missing capabilities incrementally
   
   No parallel implementation will be introduced.
   
   ---
   
   ## Expected Outcomes
   
   * Reduced configuration errors
   * Improved onboarding for new users
   * Scalable form generation from plugin schemas
   * Maintainable and extensible UI architecture
   
   ---
   
   ## Alternatives Considered
   
   **Raw JSON only**
   
   * Flexible but error-prone
   
   **Manual forms per plugin**
   
   * High quality but not scalable
   
   **Schema-driven + JSON fallback (chosen)

Re: [I] feat: JSON Schema-driven UI for APISIX Plugin Configuration [GSoC 2026 Proposal] [apisix-dashboard]

2026-03-22 Thread via GitHub


Baoyuantop commented on issue #3347:
URL: 
https://github.com/apache/apisix-dashboard/issues/3347#issuecomment-4107735329

   Thanks for the detailed proposal and PoC (#3346). The phased breakdown and 
acceptance criteria are well-structured, which is helpful for GSoC evaluation.
   
   This direction is valuable. However, there's already a related PoC in #3274 
with deeper coverage (anyOf, if/then/else, encrypt_fields + 43 tests).
   
   To avoid duplicate efforts, I'd suggest focusing on:
   1) Clarify how your approach aligns with / reuses #3274, rather than 
building two parallel engines
   2) Prioritize correctness issues first (especially form state cleanup on 
branch switching, submit payload consistency)
   3) Bind each phase to verifiable deliverables (test cases + reproducible 
demo + pass criteria)
   
   If you're interested, consider posting an "alignment plan" in this issue:
   - Which parts of #3274 you plan to reuse
   - Which capabilities/tests you'll add
   - Minimum mergeable target (MVP gate) for each phase
   
   This would make the proposal more compelling in the GSoC context.


-- 
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]



Re: [I] feat: JSON Schema-driven UI for APISIX Plugin Configuration [GSoC 2026 Proposal] [apisix-dashboard]

2026-03-21 Thread via GitHub


Baluduvamsi2006 commented on issue #3347:
URL: 
https://github.com/apache/apisix-dashboard/issues/3347#issuecomment-4104966715

   @Baoyuantop  could you review this whenever you are free? I have linked the 
prototype PR #3346 and issue #3347 with the current scope and acceptance 
criteria.


-- 
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]