[pending-task] Should PendingTaskEvent have a type field?

[justinfagnani]

There will definitely be different types of tasks, but can we standardize on any thing useful?

• What categories of tasks are there?
• Would a type field be useful across unknown tasks / consumers?
• Are there a maybe couple of very broad categories that could be agreed on? Maybe to align with some of the main-thread scheduling work?
• Should pending-task be limited to a subset of tasks to begin with? (ie, only UI-ready-blocking tasks, not say async rendering tasks?)

[jorenbroekema]

In my opinion it would be a bit difficult to define a set of types that covers it all, and I also don't really understand what such a type field would mean for the implementer? Would the type be something that, depending on the value, you do different things? Going back to https://github.com/jorenbroekema/suspense-element/ , would it for example mean that for certain types I display the fallback slot, but for some I don't (because it wouldn't make sense there)?

If we can align on types and implementation layers like mine have clear benefits of having this alignment, I'd be all for it, but it's not super clear to me yet what the "why" is exactly, I think it needs more concrete use cases perhaps.

[nicholasrice]

@justinfagnani we're exploring the use of PendingTask to support SSR async rendering, where the SSR renderer will pause rendering until PendingTasks emitted by the element are complete. I'm noticing you're making a distinction between "async rendering tasks" and "UI-ready-blocking tasks" here though, and I'm not confident I understand you completely. When you say "async rendering tasks" are you referring to work performed by the component's templating implementation (internals of LitElement, FASTElement, etc)?