UX: Prevent loading skeleton during ticket reply and preserve the current ticket state during re-fetching

[AhmedAmgadElsharkawy]

Hi everyone,

While testing the ticket reply flow, I noticed a UX friction point on the ticket details screen: submitting a reply causes the entire view to disappear and flash a full loading skeleton before displaying the updated ticket.

Looking through the client code (SupportTicketDetailPage.tsx especially), I found this:

1. Reply submission & response: Submitting a reply sends a POST request. The backend returns a 302 Found redirect rather than a 201 Created with the updated ticket entity in the response body (matching traditional form submission conventions).
2. Client re-fetch: To synchronize state after the redirect, the component triggers a re-render by increasing refreshNonce state, which issues subsequent GET requests to retrieve the updated ticket details using UseJson hook.
3. State reset & flash: When re-fetching starts, the useJson hook resets the local ticket state to null and sets loading to true. The component temporarily replaces the entire view with the loading skeleton until the GET requests resolve which make us lose the old state and causes a bad UX, especially if the fetching failed for any reason.

Proposed Improvement

We can make this much smoother on the frontend without blowing away the active view:

• Button Loading State: Disable the "Send Reply" button and show an inline spinner on the button itself while the request is in flight.
• Preserve Existing View: Keep the current ticket state intact during the background fetch instead of resetting it to null or triggering the full-page loading skeleton.
• In-Place Refresh: Once the server responds, reset the form/attachment inputs locally, update the messages in the background, and display the success toast.

I would like to check my understanding of the current flow and get your thoughts on this proposed improvement. If this direction is accepted, I would be happy to take this on and submit a PR to implement the frontend fix.

Also, long-term, is there any plan to have the backend endpoints return JSON representations directly rather than redirect responses to match the SPA philosophy, or should we continue designing the client to seamlessly bridge the current pattern?

[jesperpedersen]

@AhmedAmgadElsharkawy I think this sounds like a good direction for the application.

Please, type up a draft pull request for this. Thanks !

[AhmedAmgadElsharkawy]

@jesperpedersen Okay, I'll start working on the draft PR right away.