🦋 Changeset detected

Latest commit: c75f9a6

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}

The size of lit-html.js and lit-core.min.js are as expected.

Before committing to this direction, I think it's probably a good idea to have a plan for how to address async directives and server only templates.

Also, pushing this logic into controllers feels slightly odd since controllers may or may not have anything to do with being async or affecting server rendering.

It seems more natural to let an element itself make this decision. Random idea: await the result of update on the server.

async update(changed) {
  if (isServer) {
    await this.task.taskComplete;
    await this.otherAsyncThingComplete;
  }
  super.update(changed);
}

The intention for this feature is to provide a low level utility which can later be used by controllers (such as Task) to do async work during SSR (without the user needing to modify their element).

The multiple highlighted async use-cases that this specific PR unlocks is mostly because Controllers will initially be the one place where async work can happen. We're starting there because we want to start proving async work out starting with Task. We suspect that there will be some subtlety in doing async work well, and so we'll want to package that up into reusable pieces, and controllers seem like a good way of doing that.

Is there concern that adding this capability in ReactiveControllers may block server directives or awaiting on the element?

The concern is about exposing the API at the right level where knowledge exists about what to do on the server. It seems like this makes more sense at the element level than the controller.

The intention for this feature is to provide a low level utility which can later be used by controllers (such as Task) to do async work during SSR (without the user needing to modify their element).

Some tasks should be awaited for server rendering, others should not. Although this might be determined by a specialized task itself, it's more likely this depends on the setup in the consuming element... unless I'm missing something about the intended automation.

By analogy, you wouldn't add a feature to a self-driving car that allowed a wheel to automatically stop the car, instead you'd let it report speed and tire pressure so the system could decide what makes sense to do...

@sorvell Yeah, not all Tasks will want to run on the server, that'll be a config. And agreed that elements should be able to do async work on the server too, but currently what does async work look like in an element? Because the server should be doing fundamentally the same thing as the client, just optionally it'll await it before first render. And right now our best pattern for async work on an element is the Task controller, so it makes sense to target that as the first API, IMO.

I could easily see this becoming deprecated or just unnecessary once we have a more comprehensive pattern for elements. IMO, this need means we need to design a way for elements to have an async trap before an update.

Towards that end...

Elements can schedule updates using scheduleUpdate and potentially do async work there, but it's not a convenient override point because it's not part of the controller lifecycle.

This is why I suggested update as the spot. If we go that way, we'd want to change performUpdate to:

1. await the result of update if there is one.
2. return that result so the update itself can wait

Or something like that.

Given that some design work seems warranted, I'm just a bit uncertain about pushing this through as is.

I don't think we want to make performUpdate() async. That brings all kinds of questions of what to do with concurrent updates (namely, continue and enqueue new update vs abort), and we're actively trying to move away from async performUpdate() by adding scheduleUpdate() and deprecating returning a Promise from performUpdate().

The concern is about exposing the API at the right level where knowledge exists about what to do on the server. It seems like this makes more sense at the element level than the controller.

I think both need to be involved, because we want the system to work correctly when an element uses a controller that must do async work for initial render. Task may be configurable, but there are other abstractions that might say fetch initial data asynchronously and always want to force a wait.

I share the concern about this API being ready to commit to though. Even on a bike-shedding axis, I'm wary of adding too many "server" specific names. Is there some more general concept we're really getting at there, like "initial"*?

So I think we should hold off on merging this a bit. I'd like to review (sorry, been very busy lately!) and I think we should include in the same branch real usage of the API, like updating the real Task implementation to use it, to prove that it suits at least the current needs we have. (and maybe we could make this a private API that only Task has access to initial to gather feedback?)

I'd also like to think through if there's a version of this API where the element is more in charge (but we don't make performUpdate() async). This might look like having a new method on ReactiveControllerHost to wait for initial render until a Promise resolves. It's not a hugely different, API really, it just puts the additional responsibility on the host and reduces how much SSR needs to know about controllers.

Great discussion here! To mark that this PR is not ready to merge I'm downgrading this PR back to a draft.

Thank you Justin and Steve for your reviews!

One option that Peter suggested was to add a labs/server-task package which adds the SSR functionality to Task (without impacting the stable Task package). I'll branch off this branch to make the server-task easier to review.

I don't think we want to make performUpdate() async. That brings all kinds of questions of what to do with concurrent updates (namely, continue and enqueue new update vs abort)

IMO, we've already taken this on directly by having scheduleUpdate support asynchrony. There's already code to handle concurrent updates (that scheduleUpdate's response participates in): the next update is blocked on the current update completing.

AFAIR, we deprecated performUpdate's asynchrony specifically because we added scheduleUpdate.

To respect autoRun and the args function, I think ServerLoadedTask would need to do something like:

class ServerLoadedTask extends Task implements ServerController {
  get serverUpdateComplete() {
    this.hostUpdate();
    if (this.status === TaskStatus.PENDING) {
      return this.taskComplete;
    }
  }
}

This is maybe more about Task than the ServerController interface, but one thing that bugs me is that the easy way to use Task typically results in a 2x update even when the task really shouldn't run. Consider this slight modification of the playground example.

Here the package displayer is a separate element that takes the packageName as a property. It should only run the task if there's a packageName given. The code avoids the expensive fetch but does run the task and return the initial state, which provokes an additional update. While cheap, this isn't ideal and is probably worth avoiding, and if we do it on the server, that'll make the element render async, which again I think worth avoiding.

it's possible to finagle autoRun (commented in the example) to avoid this, but this requires involving the element, which would mean that it couldn't naively just use ServerLoadedTask.

@sorvell

I don't think we want to make performUpdate() async. That brings all kinds of questions of what to do with concurrent updates (namely, continue and enqueue new update vs abort)

IMO, we've already taken this on directly by having scheduleUpdate support asynchrony. There's already code to handle concurrent updates (that scheduleUpdate's response participates in): the next update is blocked on the current update completing.

AFAIR, we deprecated performUpdate's asynchrony specifically because we added scheduleUpdate.

Yeah, async scheduleUpdate() is fine, but sync performUpdate() is very useful, and we've had custom discussions even this week around using that for some niche cases.

This is maybe more about Task than the ServerController interface, but one thing that bugs me is that the easy way to use Task typically results in a 2x update even when the task really shouldn't run.

This is a side effect of the whole task function-calling call tree being async functions. We could rewrite things a bit so that _performTask(), run(), and the user's task function are optionally async. That would allow returning initialState or any data, or throwing synchronously, which would play slightly nicer with SSR.

It's a small optimization though, saving one microtask per task that has the next state synchronously available.

I think Task that works with the element being in control of waiting would look something like this, btw:

  async run(args?: T) {
    //...
    this.status = TaskStatus.PENDING;
    let result!: R | typeof initialState;
    let error: unknown;

    // Request an update to report pending state.
    if (this.autoRun === 'afterUpdate') {
      // Avoids a change-in-update warning
      queueMicrotask(() => this._host.requestUpdate());
      
      // afterUpdate tasks don't make sense in SSR, right?
      if (isServer) {
        console.log('skipping afterUpdate task in SSR');
      }
    } else {
      // get the host to report current task status like PENDING
      this._host.requestUpdate();
      // Tell the host to update after the task is complete?
      this._host.requestDeferredUpdate(this.taskComplete);
      // note, accessing this.taskComplete unconditionally like this defeats the lazy Promise creation we added
    }
  }

Sorry to bother here, but is this something that is still planned to be implemented at some point? Or should we look for other solutions?

Due to the use of the phrase "resolve #1434" in the PR description this PR is linked as fixing that issue, even though when reading the description fully it looks like that is not true.