-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First render event updates appear not to trigger update #549
Comments
Confirmed the issue, which is due to https://stackblitz.com/edit/lit-element-example-wrnwsh?file=index.js Longer explanation: If web components being rendered fire events synchronously to rendering, event handlers that set properties based on those events won't trigger a re-render. Although we do now consider elements that fire events when being created or when properties on them are set to be an anti-pattern (we only recommend firing events as a result of UI/asynchronous actions), legacy elements from Polymer like
The contact for We will consider the best way to address this, either in the library or via patterns, and in the fullness of time, ensuring a community-wide pattern where elements don't fire events synchronously seems the best way forward for a number of reasons. |
Fixes #549. Changes `UpdatingElement` such that updates can occur after calling `super.update()`. Changes `LitElement` such that update/render can occur as a result of rendering, for example if an event listener is triggered that sets a property.
Makes sense, thank you for the explanation! Yeah, not immediately retriggering rendering makes a lot of sense, because then you could hang the UI thread with infinite rendering. |
Note to self to address this somehow in docs, maybe Events and/or Lifecycle pages. |
Related to: #551. |
Fixes #549. Changes `UpdatingElement` such that updates can occur after calling `super.update()`. Changes `LitElement` such that update/render can occur as a result of rendering, for example if an event listener is triggered that sets a property. Update should be marked ready for additional/new updates when: 1. After the `update` method is called (e.g. after super.update(...)) 2. If `shouldUpdate` return false. Returning false indicates that this update turn should be ignored but future updates should be processed. 3. If there is an exception during `update`.
Description
Events that are triggered soon after (during?) the first render seem to not trigger an update.
Live Demo
https://stackblitz.com/edit/lit-element-example-xf7hpe?file=index.js
Steps to Reproduce
Expected Results
Actual Results
Browsers Affected
(Other browsers probably affected, but I don't have them handy.)
Versions
The text was updated successfully, but these errors were encountered: