fix(composer): show the autosave copy, and drop a posted draft - #279
Merged
Conversation
The new-thread page built its copy record without the six keys ComposerRecovery reads, so the island rendered them as themselves — "composer.autosave.saved" under the message box the moment a draft saved. The reply form's record carried them; the new-thread form's never had. Both records share one list now, and a test scans the composer components for the keys they read from the prop so a record cannot fall behind one again. Closes #275 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AZGWFg83tyN4hSR3wsPLhF
… thread Posting cleared the server draft but two paths put it back, so starting another thread in the forum offered the one just posted. A Server Action's redirect is a client-side navigation when scripting is on, so the browser's own recovery copy was never removed on the one path that mattered; and the blur that pressing Post fires raced an autosave in behind the action's own draft removal, recreating the server draft after it had gone. The browser copy is now removed when the composer unmounts mid-submit — what a successful post looks like from the browser — and a pointerdown on any submit button holds off the blur autosave until the next keystroke, so the post's draft removal is the last word. Typing after a failed submit clears the hold, so an attempt that errored still keeps its draft. Refs #275 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AZGWFg83tyN4hSR3wsPLhF
jouwdan
force-pushed
the
claude/meith-github-issues-39t98h-275
branch
from
August 27, 2026 14:13
a2e306a to
8499758
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #275
Two composer draft fixes.
1. Autosave strings rendered as raw keys
ComposerRecoveryis one island rendered by both composers. It reads six keys from itscopyprop —composer.autosave.saving/saved/failedandcomposer.recovery.available/restore/discard.replyFormCopy()built all six;newThreadFormCopy()built none, so the moment a new thread autosaved, the page printedcomposer.autosave.savedverbatim under the message box.pnpm i18n:checkcouldn't catch it: the catalog carries the messages, the page just never asked for them.apps/community/src/view/content-copy.ts— the six keys are one shared list now, spread into both records so they can't diverge.apps/community/src/view/content-copy.test.ts— scans the composer components for everyfromCopy(copy, …)they read and asserts the record a page hands them carries each key and resolves it to prose. Fails without the fix.2. A posted draft was offered on the next thread
Posting cleared the server draft, but two paths put it back, so starting another thread in the same forum offered the one just posted:
localStoragewas never removed on a successful post —pagehidedoesn't fire.drafts.remove, recreating the server draft after it had gone.apps/community/src/components/content/composer-recovery.tsxnow removes the browser copy when the composer unmounts mid-submit, and a capture-phasepointerdownon any submit button holds off the blur autosave until the next keystroke — so the post's draft removal is the last word. Typing after a failed submit clears the hold, so an errored attempt keeps its draft.e2e/composer-drafts.spec.tscovers it: autosave a thread, post it, and the next new-thread page is empty with no recovery offer and nolocalStoragecopy left.docs/guides/community/formatting.mdgains a Drafts section describing the feature and this behaviour.Validation
pnpm lint,pnpm typecheck:app,pnpm i18n:check,pnpm docs:links:check,pnpm docs:index:check,pnpm comments:check, thecontent-copyunit test, and the new e2e all pass.