Skip to content

FOLLOW-UP: Document lvt-preserve-attrs class footgun in user-facing docs (from PR #72) #75

@adnaan

Description

@adnaan

Context

This follow-up task was identified during the review of PR #72.

Source PR: #72
PR Title: feat: lvt-preserve attributes, navigate SPA nav, DOMParser script fix
Suggested by: @claude[bot] (flagged across multiple review rounds)

Task Description

lvt-preserve-attrs only protects attributes that the server template does not set. This is a subtle but important constraint that is easy to misuse:

  • If the server template sets class="card" and client JS later adds card open via classList.add, morphdom diffs against the server's class="card" (which is already present in toEl), so the copy loop skips it — and the user's open class is lost on the next diff.
  • The same applies to style, aria-*, and any other attribute the server template explicitly emits.

The behavior is correct and intentional (server retains authority over attributes it declares), but the attribute name lvt-preserve-attrs implies broader preservation than what is delivered.

Suggested action: Add a one-liner to user-facing docs/README that spells out the exact guarantee:

lvt-preserve-attrs preserves only attributes the server template does not emit at all. Attributes present in the server template are always overwritten by morphdom.

Also consider adding a test case that explicitly documents this limit (attribute present in server template is NOT preserved, showing the boundary).

Original Comment

lvt-preserve-attrs silently overwrites JS-mutated attributes that the server also controls. The comment notes this already, but it's easy to misuse: if the server template sets class="card" and JS later adds card open, morphdom diffs against toEl's class="card" (which already has the attribute), so the copy loop skips it and open is lost. Since this is a footgun with no runtime signal, the attribute docs should warn that it only protects attributes the server template does NOT emit at all.


This issue was automatically created by prmonitor from PR review comments.

Metadata

Metadata

Assignees

No one assigned

    Labels

    follow-upFollow-up task from PR reviewfrom-reviewIssue originated from PR review

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions