feat(studio): route element delete through SDK removeElement (§3.1)#1465
Conversation
Co-authored-by: Miguel Ángel <miguel07alm@protonmail.com>
This was referenced Jun 15, 2026
Collaborator
Author
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced Jun 15, 2026
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.

Summary
Routes
handleDomEditElementDeletethrough the SDK (sdkSession.removeElement) when an active session resolves the element's hf-id, falling back to the existing server-side/api/projects/{pid}/file-mutations/remove-element/path otherwise. Also documents (via// ponytail:comment) that z-index reorder (§3.4) is already SDK-cut-over because it writesinline-stylepatches throughcommitPositionPatchToHtml→persistDomEditOperations→onTrySdkPersist.Stage 7 §3.1 — Delete →
removeElementChanges
sdkCutover.ts: Extract internalpersistSdkSerializehelper (serialize → write → recordEdit → reload tail shared across ops); add exportedsdkDeletePersist(hfId, originalContent, targetPath, session, deps).sdkCutoverPersistrefactored to usepersistSdkSerialize.useElementLifecycleOps.ts: Add optionalonTrySdkDelete?callback to params; handler tries it after readingoriginalContentand before the server API call. On success: clear selection, show toast, return. Z-index reorder// ponytail:note added (§3.4 verified cut-over).useDomEditCommits.ts: ThreadonTrySdkDelete?throughUseDomEditCommitsParams→useElementLifecycleOps.useDomEditSession.ts: WireonTrySdkDeletefromsdkSession(same pattern asonTrySdkPersist).sdkCutover.test.ts: 6 new tests forsdkDeletePersist(null session, element not found, removeElement called, history recorded, reload called, error fallback).Open decisions (§7)
sdkDeletePersistrecords into StudioeditHistory(persistent), consistent withsdkCutoverPersist. SDK session also has in-memory history. Two stacks coexist — same as style/text edits today. s7.4 force-reload after undo/redo keeps Studio history authoritative; no regression introduced.inline-stylepatches → already SDK-cut-over assetStyle. No DOM-node reordering; no SDK reorder op exists or is needed. Documented with// ponytail:comment.Verification
bun run build✅bun run test✅ (26 sdkCutover tests pass, full suite green)bunx oxlint/bunx oxfmt --check✅🤖 Generated with Claude Code