Part 1 was about waiting well. Part 2 was about not waiting at all. This one is about a value I needed in a component that never created it, and ab...
For further actions, you may consider blocking this person and/or reporting abuse
The form-vs-DOM-tree distinction for useFormStatus is the part I'd have gotten wrong. Good catch on the react-dom import too, that's exactly the kind of thing that fails silently instead of throwing. Curious whether you've tried this pattern with Next.js Server Actions specifically, or kept the series to plain React so far.
Glad you caught the
react-domimport, Tarun. That one fails silently, which is the worst kind of bug because you start questioning everything except the import line. 🙂I’ve kept this series framework-agnostic so far. I have written about Next.js Server Actions elsewhere, mostly auth stuff and cache invalidation, though I haven’t specifically paired those posts with
useFormStatus.My expectation is that the
useFormStatuspart works the same way with a Server Action, since the hook is reading the pending state of its parent form rather than caring about the implementation behind the form’saction. But I haven’t demonstrated that combination in one of my posts yet.The auth side is here: Next.js 16 Server Actions Security: The Auth Check Most Developers Miss.
I also covered optimistic UI with Next.js Server Actions here: My Next.js 16 Optimistic UI Looked Perfect. Then Someone Clicked It Five Times Fast.
For this series, I deliberately kept the examples in plain React so the hook mechanics aren’t buried under framework-specific auth and cache APIs. The
PlaceOrderButtonpattern here is the part I’d be interested in trying with a Server Action next.Appreciate the detailed reply. Makes sense, if useFormStatus is just reading the form's pending state it shouldn't care what's calling the action. Gonna check out your auth check post, that's exactly the kind of Server Actions gotcha I keep hearing about. If you do try the PlaceOrderButton pattern with a Server Action, curious whether pending from useFormStatus and any transition state from useTransition ever end up fighting each other.
Thanks, Tarun. Good question. I cover both cases in my Server Actions tutorial. For a form action I use
useFormStatusin the child button, and for anything outside a form like a delete button I useuseTransition. I haven't written the case where both get used on the same interaction, so I don't have a tested answer for that part yet.My expectation is that manually wrapping a form action in
startTransitioncould make the pending states confusing, since you'd be introducing another transition state around the same interaction instead of just letting the form action handle it. I haven't tested that combination yet, though. If I build out the Server Action version ofPlaceOrderButton, I'll try that case on purpose and see what actually happens rather than guessing.That makes sense, the pending state from startTransition would basically be a second source of truth competing with the one useFormStatus already reads off the form. If you do end up testing it, I'd guess the safer pattern is to only wrap the non-form parts of the click handler in startTransition and just let the form action own its own pending state, but that's a guess too. Would genuinely read that follow up post if you write it.
Yeah, that's the case I'd want to test rather than guess about. The split you're describing, where the form action owns its own pending state and
startTransitiononly wraps the non-form parts, makes sense on paper, but I'd want to see what actually happens when they overlap before recommending it. If I do the Server Action version, I'll definitely test that case on purpose. 🙂Nice debugging of
useFormStatus! You'll cover all the functions in Next.js soon! 👍Thank you so much! 😊 More React 19 and Next.js content is definitely coming, along with plenty of other dev topics!
Now I'm wondering about the mirror of your form attribute case. A button rendered through createPortal sits outside the form in the DOM but inside it in the component tree, so it should keep reading pending correctly. Did you happen to try that one?
That’s a really good edge case. useFormStatus follows the React tree rather than the DOM tree, so a button rendered through createPortal can still read the parent form’s pending state even though it’s mounted elsewhere in the DOM. I didn’t cover portals in this post, but that’s definitely a useful nuance to keep in mind.