Baoyuantop commented on issue #3327:
URL:
https://github.com/apache/apisix-dashboard/issues/3327#issuecomment-4066509455
Hi @vanshaj2023, thanks for reporting this and for the detailed analysis.
I took a closer look at the data flow and wanted to share some findings that
may affect the fix approach.
## How schema is actually loaded
In the current codebase, the plugin schema is **not** fetched individually
when the editor drawer opens. Instead, it comes from a **cached plugins list**
that was already loaded via `useSuspenseQuery`:
**In `FormItemPlugins/index.tsx` (Routes/Services forms):**
```
useSuspenseQuery(getPluginsListWithSchemaQueryOptions(...))
→ pluginsOb.pluginSchemaObj (Map of all plugin schemas)
→ pluginsOb.curPluginSchema (synchronous lookup by plugin name)
→ passed to PluginEditorDrawer as schema prop
```
**In `PluginMetadata.tsx`:**
```
useSuspenseQuery(...) + useQueries(...)
→ pluginsOb.__schemaMap (Map)
→ pluginsOb.curPluginSchema (synchronous lookup)
→ passed to PluginEditorDrawer as schema prop
```
This means the `schema` prop is derived **synchronously** from
already-cached data — there is no separate async fetch happening when the
drawer opens.
## Why the described scenario is unlikely to trigger
1. **Network failure before plugins list loads**: `useSuspenseQuery` throws
to the nearest Suspense/Error boundary → the entire form does not render →
drawer never appears
2. **Network failure after plugins list was cached**: Schema is already in
the TanStack Query cache → drawer gets the schema synchronously from the cache
→ no loading state needed
3. **The `curPluginSchema` getter has a fallback**: `if (!d) return {}` —
returns an empty object (not `undefined`), so `!schema` evaluates to `false`,
meaning it will not actually get stuck in the loading skeleton
The realistic edge case where this *could* trigger is if a plugin schema
field is genuinely missing/undefined in the API response — a data quality issue
rather than a network failure.
## Recommendation
That said, `isLoading={!schema}` is indeed a code smell — it conflates "not
yet loaded" with "data is empty/missing". A minimal fix would be appropriate:
**Option A (minimal):** Since schema is synchronously derived, remove the
loading dependency on schema:
```tsx
<FormItemEditor
name="config"
h={500}
customSchema={schema}
isLoading={false}
required
/>
```
**Option B (defensive):** Add explicit `isSchemaLoading` / `schemaError`
props to `PluginEditorDrawer` so the parent controls the loading/error states,
rather than the drawer inferring them from `!schema`. This would be more
future-proof if we ever switch to per-plugin schema fetching.
I would lean toward **Option A** for now since it matches the actual data
flow, and we can evolve to Option B if the architecture changes later. Adding a
full error/retry UI for a scenario that does not currently occur would be
over-engineering.
--
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]
