-
Notifications
You must be signed in to change notification settings - Fork 939
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow SSR renderers to produce asynchronous values #3467
Conversation
🦋 Changeset detectedLatest commit: 60986e2 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
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 Benchmark ResultsSummarynop-update
render
update
update-reflect
Resultslit-element-list
render
update
update-reflect
lit-html-kitchen-sink
render
update
nop-update
lit-html-repeat
render
update
lit-html-template-heavy
render
update
reactive-element-list
render
update
update-reflect
|
One open question for me I didn't look into yet is how this integrates into a streaming response like Koa. I suspect we'll need a utility that can pipe into a Stream correctly, but we don't seem to have an example of that in the monorepo yet. Adding a test that emulates a Koa environment could be a blocker for this PR. |
I think we just need the utility to be an async generator that yields out strings as they resolve that can be fed into And you can test that by making a |
This could be micro-optimization, but because of the overhead we saw with async generators before I would like to not incur the overhead of a promise and microtask for synchronous strings. It just seems like that would diminish or possibly eliminate the benefit we get from using sync generators. |
I added a RenderResultReadable that consumes a RenderResult. It should be about as optimal as we can get:
This should be usable with server frameworks like Koa like: app.use('/', async (context) => {
const result = render(...);
context.body = new RenderResultReadable(result);
} (Koa automatically pipes the body to the response when it's a Readable). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! A bunch of small comments.
|
||
/** | ||
* Render an element's light DOM children. | ||
*/ | ||
abstract renderLight(renderInfo: RenderInfo): IterableIterator<string>; | ||
abstract renderLight(renderInfo: RenderInfo): RenderResult | undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why can this now be undefined
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it was a bad assumption that just because a template had <my-el>${renderLight()}<my-el>
that <my-el>
actually has a renderLight()
implementation. So it makes sense to me that renderLight()
would have nothing to render and could return undefined
rather than an empty iterable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ping
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oops, forgot to send my comments
I added lit/lit.dev#1005 for the corresponding lit.dev update. |
|
||
/** | ||
* Render an element's light DOM children. | ||
*/ | ||
abstract renderLight(renderInfo: RenderInfo): IterableIterator<string>; | ||
abstract renderLight(renderInfo: RenderInfo): RenderResult | undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ping
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! We should update the koa demo to use the RenderResultReadable
. There's already some maintenance needed for the demo #3118 so could be part of that? Maybe the readme update/cleanup should be a separate task so we don't duplicate work across updating readme and the docs on lit.dev.
Ah, I forgot this was in the monorepo already. I'll update it. I kind of want things like this to be in the /examples folder I was talking about a few eng meetings ago. |
I simplified RenderResult as requested, and the implementations resulting from that. Worth a new review from everyone. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, changing base branch back to main produced a conflict to be resolved. New changes look good!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This is a breaking change that expands the return types of
render()
and the ElementRenderer methods.Addresses #3219