This week was about turning a bunch of edge cases into product behavior.
A lot of startup work looks like “feature building” from the outside, but inside the repo it is often something quieter: remove flicker, make a redirect wait for the URL, preserve a draft route before it exists, standardize a menu, restore an old version without breaking metadata, and make sure the tests catch the next regression. That was this week.
The first visible editor fix was hover stability. Query blocks and embeds were creating flicker around block hover actions, so in PR #759 I changed the hover behavior to avoid attaching actions to block types that can create unstable pointer bridges, follow focused collapsed selection while editing, and position actions in a way that avoids the tiny gaps that cause UI jitter. This is exactly the sort of detail that makes a rich text editor feel either delightful or haunted.
Then I went deeper into draft routing. PR #765 improved lazy draft route handling by reserving public draft routes before persistence, routing private drafts through opaque generated paths, and preserving discard/return behavior. This is a very state-machine-heavy part of Seed: the user needs to enter the editor immediately, but the product should not create empty draft records too early, leak private paths, or lose the correct breadcrumb context. The implementation added coverage for draft shells, breadcrumbs, child creation, and editor change detection.
I also re-enabled the browser hydration integration suite in PR #770. Hydration tests can be fragile if they depend on React internals or route-specific UI, so I moved the check toward a stable hydration marker and verified the client bundle hydrates without runtime page errors, hydration console errors, or error boundary UI. For a Remix/React app that serves public documents, hydration correctness is not just a test detail — it is part of publishing reliability.
Redirect behavior got another reliability pass in PR #771. When a redirected document resolved before the URL had been replaced, the UI could briefly render the target document under the stale route. I changed that into an explicit loading state, tightened redirect max-depth handling, and added tests for query caching, version behavior, and route replacement. It is another example of Seed’s architecture having to care about document identity at a level most apps can ignore.
The biggest user-facing feature of the week was version restore in PR #730. I added a restore action to document version history so older versions can be republished as the latest version, on both desktop and web. The implementation handles permissions, cache invalidation, navigation, draft cleanup after successful restore, and shared restore-change generation for both content and metadata. I especially like this feature because it makes publishing feel less scary. If every publish feels irreversible, people hesitate. If version history has a real restore path, people can move faster.
On the UI architecture side, I standardized option menus in PR #772. Several surfaces had one-off dropdown implementations; I replaced those with a shared OptionsDropdown that supports custom triggers, disabled items, nested items, content styling, and consistent destructive action ordering. This is the kind of frontend architecture work that compounds. Every future menu becomes less bespoke, easier to test, and more consistent for users.
I also did some publishing/client cleanup: document changes now publish through the Seed client (commit 504632dad), the old daemon publish path helper was removed (commit 88d0b0d57), and the create-document-change RPC was removed from the document flow (commit bf2948231). Not glamorous, but it keeps the architecture moving toward fewer special cases.
There were also a few important polish passes: a shared document delete dialog (commit e3da212ea), grid media breakout constraints (commit 489d88bbb), sidebar bookmark deletion (commit 3b258ed66), and keeping document actions accessible in the tools row (commit f2a0e647c). I also pinned desktop Windows builds to windows-2022 (commit 149f9e5b7) and covered profile descriptions/client exports in desktop tests (commit 6f49c6810).
This week reminded me that a product becomes trustworthy through hundreds of these decisions. The user never sees “route replacement waiting” or “lazy draft reservation,” but they do feel the absence of surprise.
Code trail
My question from this week:
how much complexity can a state machine absorb so the user never has to?
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime