fix: resolve Lit dev warnings from AppKit web components - #5629
Merged
Conversation
- w3m-wallet-send-view: make getMessage() a pure function instead of mutating @State() inside render() - w3m-input-address: remove child expressions from textarea elements, rely on .value binding only - w3m-router-container: defer viewDirection mutation via queueMicrotask to avoid change-in-update warning from updated() - w3m-all-wallets-list: move setAttribute() from render() to firstUpdated() Closes REOWN-4559 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
9 Skipped Deployments
|
Contributor
|
All contributors have signed the CTA ✍️ ✅ |
svenvoskamp
approved these changes
Apr 13, 2026
Contributor
Author
|
I have read the CTA Document and I hereby sign the CTA |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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
Fixes 4 Lit development warnings emitted by AppKit internal web components during normal modal usage (REOWN-4559).
Technical Report
Problem
Four Lit dev warnings were firing in the browser console during normal AppKit modal usage, creating noise for developers integrating AppKit.
Root Cause Analysis
Each warning had a distinct cause in a different component:
change-in-update):render()calledgetMessage()which mutatedthis.message— a@state()reactive property. Setting reactive state during render triggers a new update cycle.expression-in-textarea): Two<textarea>elements had both.value=\${...}binding AND child expression\${this.value ?? ''}. Lit doesn't support expressions inside<textarea>.change-in-update):updated()lifecycle calledonViewChange()which synchronously setthis.viewDirection(reactive state), triggering another update during the current cycle.change-in-update):render()calledthis.setAttribute('data-mobile-fullscreen', 'true')— DOM mutation during render.Approach & Reasoning
Fix 1 — Pure function (chosen over computed property):
Converted
getMessage()from a state-mutating method to a pure function that returns the message. The return value is passed as a local variable throughrender()andbuttonTemplate(message). Removed the@state() private messageproperty entirely since it was only set and consumed within the same render cycle. The early-return priority order was carefully reversed to match the original last-assignment-wins semantics:SELECT_TOKEN > INCORRECT_VALUE > ADD_AMOUNT > INSUFFICIENT_FUNDS > ADD_ADDRESS > INVALID_ADDRESS > PREVIEW_SEND.Fix 2 — Remove child expressions (only option):
Removed
\${this.value ?? ''}child text from both textarea elements. The.valueproperty binding is the correct and sufficient mechanism for controlling textarea content in Lit. The child text was redundant — it setsdefaultValuewhile.valuesets the current value.Fix 3 — queueMicrotask (chosen over setTimeout/requestAnimationFrame):
Wrapped
this.viewDirection = ...inqueueMicrotask(). This defers the state mutation past the current Lit update cycle but runs before the next browser paint, so there's no visual gap in the CSS transition animation.setTimeout(0)would run after paint (causing a flash), andrequestAnimationFramecould miss the current frame.Fix 4 — Move to firstUpdated (chosen over willUpdate/updated):
Moved
setAttributetofirstUpdated()sincemobileFullScreenis initialized fromOptionsController.state.enableMobileFullScreenwith no subscription — it never changes after init. If it could change dynamically,updated()with achangedPropertiescheck would be needed instead.Verification
Test plan
🤖 Generated with Claude Code