What changed
As of @livetemplate/client v0.18.1 (client PR livetemplate/client#148, fixing livetemplate/client#147), class and attribute state applied by lvt-el: actions is now preserved across morphdom re-renders. Before this, a class toggled by lvt-el:toggleClass was stripped by the next unrelated render — a dropdown held open with lvt-el:toggleClass:on:click="open" closed under the user.
The reference docs still describe lvt-el: purely as fire-and-forget DOM actions and don't state this guarantee. The dropdown example in content/reference/client-attributes.md (the "DOM Event Trigger Examples" section, ~line 469) is exactly the pattern that used to break — so it's the natural place to document that it now works reliably.
What to add
In content/reference/client-attributes.md, add a short subsection under lvt-el: (near the methods table / DOM-event examples) covering the overlay semantics:
-
The guarantee: state set by lvt-el:addClass/removeClass/toggleClass/setAttr/toggleAttr survives subsequent re-renders. You can hold UI state (dropdown open, disclosure expanded, popover shown) client-side and an unrelated server render won't wipe it. (Requires client ≥ v0.18.1.)
-
The precise rule — a client-owned overlay on server state:
- Conflict (client wants a class/attr the server doesn't emit, or vice versa) → the client value wins and persists until the client itself reverses it (e.g.
removeClass / a toggle back) or the element is removed.
- Agreement (the server starts emitting the same value) → the server reclaims ownership; the overlay stops applying.
-
Boundaries worth stating so nobody is surprised:
Refs
What changed
As of
@livetemplate/clientv0.18.1 (client PR livetemplate/client#148, fixing livetemplate/client#147), class and attribute state applied bylvt-el:actions is now preserved across morphdom re-renders. Before this, a class toggled bylvt-el:toggleClasswas stripped by the next unrelated render — a dropdown held open withlvt-el:toggleClass:on:click="open"closed under the user.The reference docs still describe
lvt-el:purely as fire-and-forget DOM actions and don't state this guarantee. The dropdown example incontent/reference/client-attributes.md(the "DOM Event Trigger Examples" section, ~line 469) is exactly the pattern that used to break — so it's the natural place to document that it now works reliably.What to add
In
content/reference/client-attributes.md, add a short subsection underlvt-el:(near the methods table / DOM-event examples) covering the overlay semantics:The guarantee: state set by
lvt-el:addClass/removeClass/toggleClass/setAttr/toggleAttrsurvives subsequent re-renders. You can hold UI state (dropdown open, disclosure expanded, popover shown) client-side and an unrelated server render won't wipe it. (Requires client ≥ v0.18.1.)The precise rule — a client-owned overlay on server state:
removeClass/ a toggle back) or the element is removed.Boundaries worth stating so nobody is surprised:
lvt-ignore/lvt-ignore-attrsworkarounds for holding a client-set class (which never worked forclassanyway; see FOLLOW-UP: Document lvt-preserve-attrs class footgun in user-facing docs (from PR #72) client#75).Refs
lvt-ignore-attrscan't protectclass).content/reference/client-attributes.md(lvt-el:reference + the DOM Event Trigger dropdown example ~line 469).