lxbme commented on issue #3417:
URL:
https://github.com/apache/apisix-dashboard/issues/3417#issuecomment-5088243391
@moonming The "Still to do" section involves major, deep-level changes that
require higher-level decisions. It might be best for you (or another
maintainer) to take over this part, or provide explicit guidance/decisions on
how to proceed.
### Submit pipeline: "strip-then-restore" → dirty-fields (Architecture item,
#3417)
`pipeProduce` deep-cleans **all** empty values from a submit body and then
patches known exceptions back one incident at a time (plugins re-attached
verbatim, `discovery_args: {}` restored). Any field that is
meaningful-when-empty is pre-broken until another exception is added — the
class behind #3269/#3277 (inline upstream name/desc/labels) and #3376
(`discovery_args`). The proposed inversion is dirty-fields-based submission:
overlay only the fields the user actually changed onto the fetched original and
PUT the full result, so nothing is stripped and every restore-exception retires.
I'm asking before doing it because it's the largest, highest-risk change
here — it touches every form's submit path and leans on react-hook-form's
`dirtyFields`, so a mistake reintroduces the same silent-data-loss class.
Meanwhile the known cases are already fixed, and the new round-trip invariant
test (create → read → no-op edit-save → deep-diff) now catches this class in
CI. Given that, do you want the full inversion now, or is the current mitigated
state acceptable with this deferred as a tracked improvement? (A lighter middle
option: strip only UI-only `__*` keys and keep every schema-defined empty.)
### Dual UI library: replace `ProTable` with a Mantine-native table
(Architecture item, #3417)
`antd` + `@ant-design/pro-components` exist only for `ProTable` — the 12
list pages (all `search={false} options={false}`, i.e. plain paginated grids)
plus one `EditableProTable` (the upstream nodes editor). Everything else is
Mantine. The cost is continuous and unmitigated: the `antd-vendor` chunk is
~2.1 MB (~668 KB gzip, the largest chunk) and loads on every list page and any
form with an upstream; list pages render a second design language next to
Mantine; and it carries a dedicated `@ant-design/v5-patch-for-react-19` shim.
It's not a bug — nothing breaks — but every user pays it on every load.
The proposal is to replace all 13 usages with a Mantine-native table and
drop antd entirely (all-or-nothing — the editable nodes grid must migrate too,
or the chunk stays), phased as the 12 read-only tables first (well covered by
existing CRUD/pagination/bulk e2e) then the editable grid last. The decision
I'd want your call on, since it changes a framework-level dependency:
`mantine-react-table` (feature-complete and Mantine-native, but itself a
sizeable dep on `@tanstack/react-table`) versus a hand-rolled Mantine `Table`
plus the existing pagination helper (no new UI framework, more code —
especially for the editable grid). Is this something you want done, and if so
which approach do you prefer?
--
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]
