fix(editor): preserve custom HTML by blocking lossy visual conversion#362
Open
heyramzi wants to merge 1 commit intouseplunk:nextfrom
Open
fix(editor): preserve custom HTML by blocking lossy visual conversion#362heyramzi wants to merge 1 commit intouseplunk:nextfrom
heyramzi wants to merge 1 commit intouseplunk:nextfrom
Conversation
Member
|
The reason the destructive action is there in case there is an edge where a template gets incorrectly identified but is parseable. This would allow the user to switch between modes, in your solution this is no longer possible. To completely lose a template you would need to press the destructive button AND save the template. You can always refresh the page to discard the changes. |
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
Prevent templates with unsupported custom HTML from switching into the visual editor, where the markup would be normalized into a lossy TipTap representation.
Problem
The editor already detects custom HTML and warns that visual mode cannot preserve it faithfully. But the current dialog still offers a destructive
Switch Anywaypath, which makes it too easy to mutate production email markup accidentally.This is especially risky for templates that depend on:
What changed
Switch Anywaypath from the custom HTML warning dialogWhy this approach
The safe path already exists: users can continue editing in HTML mode and still preview the rendered email without converting the source into visual-editor content. Blocking the destructive transition preserves the original template instead of asking users to make an unsafe choice.
Verification
yarn vitest run --config ./vitest.mode-guards.config.cjs apps/web/__tests__/EmailEditor/modeGuards.test.tsNote: the repository's default Vitest setup requires a database and runs global DB initialization for all suites, so I used a minimal temporary config to verify this pure unit test in isolation.