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]
