🦋 Changeset detected

Latest commit: b359737

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

_{tachometer-reporter-action v2 for Benchmarks}

This is a difficult choice. Updated we can be pretty sure all computed properties should be synced by then. Also we know DOM will always be ready in the task. Can you spin up an example real quick with a task that accesses a @query and see how it looks DX-wise?

An example can maybe be a list of items with a [selected] attribute or something like select and option but you don't hook the value into the Lit data system

@e111077 yeah, I can add that as a test. A task will not be able to see rendered updates though. I think we need to find a case where something doesn't work at all, not just that we get a double-render, and let that guide us. If someone wanted to trigger a task based on updated shadow root contents... is that a supported case?

I thought we kind of resolved to do this a while back, based on this comment: #1499 (comment)

But... do we need this to be configurable? runAfterUpdate: true?

Personally don't care about a test case too much just want to investigate the DX. Like does the queried property go in the arguments list now? It won't trigger a re-render when it updates but it will trigger dirty props etc.

I mean to add the test case as a reviewed, checked-in, working example of the DX, with some assertions about whether it works. I don't think this will be a good case with the new timing, so I want to get it in and have eyes on it.

I added the test/example (didn't push yet) and... I don't know. It might be better to take the double-render hit on pending tasks.

For many cases, and especially SSR compatibility, update timing is better. So I wonder if we should have an option, and what the default should be? Is depending on DOM common? Could tasks using updated timing skip SSR?

If we keep it as so we push people towards the data system rather than accessing DOM directly which is arguably "idiomatic Lit".

So someone in updated or firstUpdated can access the DOM, update a reactive property dependency in the Task props array, and then the rerender on update can catch it. The Task may run twice (perhaps noop the first time) but the element in both cases would lifecycle twice. But in the cases where state doesn't rely on DOM (a fully SSR-able component) then there is no double render.

Idk drawbacks either way, but I'd argue the DOM case is not as common but not uncommon

What about:

  autoRun?: boolean | 'afterUpdate'

The default timing would be hostUpdate and afterUpdate would revert to the current timing. afterUpdate probably wouldn't be SSR compatible.

@e111077 I added a autoRun: 'afterUpdate' option, and I think it might be a good solution. I pushed the change and tests that show it working with DOM.

(I can't for the life of me figure out why the task tests can't see the lit package though)

Also wondering why not willUpdate? That would allow fetches to be completed on the server and send pure HTML to the user... Oh I guess reactive controllers don't have hostWillUpdate.

I think letting the user select the lifecycle like this is a decent idea. Would be cool if we could enable server fetches though

Yeah, we don't have hostWillUpdate() and if we did it would go before willUpdate() as the other callbacks do, which I don't think would be very useful.

I think we can enable server fetches - easier - with the new default timing. @kevinpschaaf had a branch that made SSR wait for async controllers, and this timing lets us know sooner that a task will have been started.