- From: Steve Orvell <notifications@github.com>
- Date: Mon, 29 Apr 2024 06:38:40 -0700
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Monday, 29 April 2024 13:38:44 UTC
This proposal is not related to signals. It's for scheduling tasks that can effect a DOM tree. The justification is pretty straightforward: you want to do some arbitrary work on a parent and a child. If you do the work on the child first, the work on the parent might invalidate the work you do on the child. Therefore, it's better to schedule the work such that the parent work comes before the child work. This provides an opportunity to efficiently customize the child work based on its updated state. This is a common need in applications and frameworks. Putting the scheduler in the platform means this work can more easily be scheduled in an interoperable way. _Then why are signals mentioned at all here?_ They are simply one of many ways it's possible to have this need to accomplish a set of work spread across a series of nodes in the DOM tree. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/1055#issuecomment-2082778535 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/1055/2082778535@github.com>
Received on Monday, 29 April 2024 13:38:44 UTC