Skip to content

fix(editor): preserve custom HTML by blocking lossy visual conversion#362

Open
heyramzi wants to merge 1 commit intouseplunk:nextfrom
heyramzi:fix/protect-custom-html-mode-switch
Open

fix(editor): preserve custom HTML by blocking lossy visual conversion#362
heyramzi wants to merge 1 commit intouseplunk:nextfrom
heyramzi:fix/protect-custom-html-mode-switch

Conversation

@heyramzi
Copy link
Copy Markdown

@heyramzi heyramzi commented May 2, 2026

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 Anyway path, which makes it too easy to mutate production email markup accidentally.

This is especially risky for templates that depend on:

  • inline styles
  • CSS classes
  • custom attributes
  • table-based layout
  • wrapper elements that are valid for email HTML but not represented in the visual editor

What changed

  • extracted mode-switch decisions into a small pure helper
  • kept HTML mode authoritative for unsupported templates
  • removed the destructive Switch Anyway path from the custom HTML warning dialog
  • clarified dialog copy so the user understands why the template remains locked to HTML mode
  • added focused tests covering initial mode detection and blocked visual-mode switching for custom HTML

Why 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.ts

Note: 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.

@driaug
Copy link
Copy Markdown
Member

driaug commented May 2, 2026

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants