mirror of
https://github.com/multica-ai/multica.git
synced 2026-07-06 05:49:12 +02:00
79dc8cfc6e
Sending a comment on a slow connection looked broken: the comment showed up in the timeline (server insert + comment:created WS broadcast) while the composer still held the text with a spinning button — looking like it was both posted and stuck pending. Root cause is that the composer cleared only *after* awaiting the network, with no in-flight lock, so the gap between "server accepted" and "input cleared" was visible. Switch all three composers (comment, reply, chat) to a pessimistic submit that matches TanStack Query's form guidance (reset after success, not optimistically): - While the send is in flight, lock the editor (pointer-events-none + dim, the documented way to make ContentEditor non-interactive — it can't toggle Tiptap's `editable` post-mount) and keep the submit button in its loading state. The text stays put, clearly reading as "sending". - Clear the composer (editor + draft) ONLY once the server accepts. A failed send now keeps the draft instead of silently discarding it — submitComment / submitReply return a success boolean the composer gates the clear on, fixing a pre-existing case where a swallowed error still cleared the box. Chat already cleared on success and disabled its button while submitting; it only needed the in-flight editor lock for parity. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>