AnchorsPanel's register and deregister actions replace the anchors table with a full loading skeleton via reload()

[Jagadeeshftw]

📌 Description

Both register() and deregister() in AnchorsPanel (src/components/AnchorsPanel.tsx) call reload() from useAsync after a successful mutation. reload() immediately sets state to { status: "loading" }, which swaps the entire anchors Card body — the status filter buttons, search box, and table — for a bare TableSkeleton until the re-fetch resolves, then re-renders everything from scratch. Every registration or deactivation therefore causes the whole anchors list to flash out and back in, discarding the user's scroll position within the table and any visible sort indicator state momentarily, purely to reflect what is usually a single added/changed row. useAsync's refresh() exists precisely to re-fetch without this disruption and is already the established pattern this codebase uses elsewhere for exactly this kind of "silently pick up the latest data" need.

🧩 Requirements and context

• After a successful register() or deregister(), the anchors list should update without dropping back to a full loading-skeleton state.
• The status filter, search box, and sort state must remain visible and unaffected throughout the update.
• The existing toast notifications and the pending state used to disable the register form while submitting must be unchanged.

🛠️ Suggested execution

• In src/components/AnchorsPanel.tsx, destructure refresh from useAsync(load) alongside (or instead of) reload, and call await refresh() in both register() and deregister() instead of reload().
• Extend src/components/AnchorsPanel.test.tsx with a test that registers a new anchor and asserts the filter buttons/search box/table remain rendered throughout (no interim TableSkeleton), unlike a reload()-driven flash.

✅ Acceptance criteria

• Registering or deactivating an anchor no longer replaces the anchors table with a loading skeleton.
• The status filter, search box, and current sort remain visible throughout the update.
• Existing toast and pending-state behavior are unchanged.

🔒 Security notes

No new attack surface; a client-side UX consistency fix reusing an already-authenticated read endpoint.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours

[Menjay7]

Hi! I came across this issue and would love to work on it. I have experience with similar tasks and I'm confident I can investigate, implement a clean solution, and thoroughly test it before submitting a PR. If the issue is still open, I would appreciate it if you could assign it to me. I’ll prioritize this immediately and ensure a reliable solution is delivered as soon as possible. Thank you!

[mayborn005]

Hello @maintainer, I’ve gone through the requirements and I’m confident I can implement a proper solution that matches the acceptance criteria. Kindly assign this issue to me. And I will deliver at the shortest possible time.

[Primex-Tech]

i will love to solve this issue. i solved 1 for you earlier

[Jagadeeshftw]

Assigned, @Menjay7! Go ahead and open a PR referencing this issue when it's ready. Join our group if you have questions: https://t.me/+vTbe0hOUKrFhNTJl