kovakmedya
f3442e644a
User reported that hitting 'İşleme Al' (and every sibling transition
button) succeeded server-side but the UI didn't update — they had to
refresh manually. router.refresh() from the client useEffect was racing
Next 16's RSC payload cache in production and losing.
Replaced the round-trip pattern with the canonical Next approach:
the server action does revalidatePath as before, then calls
redirect(`/jobs/$jobId?flash=<key>`). redirect() throws NEXT_REDIRECT
inside the action, the framework navigates the client, and the
destination page gets a fresh RSC payload — no client-side cache layer
to fight.
Actions wired:
- acceptJobAction → ?flash=accepted
- handToClinicAction → ?flash=handed
- approveAtClinicAction → ?flash=approved
- requestRevisionAction → ?flash=revision
- markDeliveredAction → ?flash=delivered
- cancelJobAction → ?flash=cancelled
Because redirect() never returns, the success branch of every button's
useEffect was now dead code. Trimmed every panel button to only watch
state.error (errors still come back through useActionState the normal
way) and removed the now-unused useRouter / router.refresh wiring.
Toast handling moved to a single client island:
- components/flash-toast.tsx: reads ?flash, toasts the matching
Turkish message, then router.replace's the URL without the param
so a manual reload doesn't re-fire the toast. A useRef guard
blocks the StrictMode double-mount in dev.
- Mounted once in (dashboard)/layout.tsx wrapped in <Suspense> per
Next's requirement for useSearchParams in a layout.
Net result: tap a button, ~400ms later the page is on the new state,
toast confirms it. No manual refresh, no cache mystery.