lit-query: controller render method

[EskiMojo14]

The Lit Tasks API includes a render method which simplifies rendering based on task status:

  render() {
    return html`
      ${this._myTask.render({
        initial: () => html`<p>Waiting to start task</p>`,
        pending: () => html`<p>Running task...</p>`,
        complete: (value) => html`<p>The task completed with: ${value}</p>`,
        error: (error) => html`<p>Oops, something went wrong: ${error}</p>`,
      })}
    `;
  }

It would be nice for consistency if the query controllers did the same:

  render() {
    return this.repo.render({
      pending: () => html`Loading...`
      error: (query) => html`Error: ${query.error.message}`
      success: (query) => html`
        <h1>${query.data.name}</h1>
        <p>${query.data.description}</p>
        <strong>${query.data.stargazers_count} stars</strong>
      `
    })
  }

It seems fairly simple to implement, so I'm happy to open a PR if this is wanted. (I don't particularly understand the tests though, it seems like they intentionally avoid using lit itself for some reason)

[yudin-s]

This seems reasonable as a thin convenience layer, especially because Lit's Task.render() has already set that expectation for Lit users.

I would keep it as a small adapter helper over the existing query result shape rather than changing the query state model.

Something like:

repo.render({
  pending: () => html`Loading...`,
  error: (query) => html`Error: ${query.error.message}`,
  success: (query) => html`${query.data.name}`,
})

would mostly be sugar for:

if (repo.result.isPending) return pending()
if (repo.result.isError) return error(repo.result)
return success(repo.result)

The caveat is naming. TanStack Query normally uses pending, error, and success states, while Lit Task uses initial, pending, complete, and error. I would mirror TanStack Query's state names even if the API is inspired by Lit Task.

For tests, avoiding full Lit rendering may be intentional: the controller can be tested as state behavior without pulling in DOM/render assertions. A good PR shape might be:

• unit tests for branch selection
• no requirement to render actual DOM
• docs showing the Lit template usage

As a proof of concept, this could even start as a userland helper. If it feels natural, moving it into the Lit adapter makes sense.