You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 30, 2025. It is now read-only.
If we know the child returns a synchronous value, we can simply return a value from the child and assign it to a variable in the parent. This is already implemented, but at the time of implementation we had a <yield> tag instead of a <return> tag, so it needs to be renamed.
Async
I think this should probably be a separate task
Parent
If we don't know the value is sync, we need to use an async compilation - treat the returned value as maybe a promise. We'll wrap any reads of the tag variable in a fork call.
The parent on the server needs to register and pass a "dummy" bound signal to the child
The parent in the browser needs to register the passed signal
The registration ids of the above need to be the same
The child on the server should serialize the bound signal at AccessorChars.TAG_VARIABLE in its scope
Additional consideration/optimization
We may not need to bind the signal that is passed to the child. When rendered client-side, the parent scope was being stored at scope._ until #114, so if we re-attached the parent (something that's probably going to be necessary for cleanup anyways), we could just pass that in tagVarSignal instead of null and relying on it being bound.
However, this means that we need to ensure that the parent is serialized, which is slightly more involved than the above plan for resuming, but it does mean no additional object would need to be created for tag variables:
The server could register statically instead of creating a new object for each render
The client could skip bindSignal which creates a new object and 3 closures.
The text was updated successfully, but these errors were encountered:
HTML Output
Sync
If we know the child returns a synchronous value, we can simply return a value from the child and assign it to a variable in the parent. This is already implemented, but at the time of implementation we had a
<yield>
tag instead of a<return>
tag, so it needs to be renamed.Async
I think this should probably be a separate task
Parent
If we don't know the value is sync, we need to use an async compilation - treat the returned value as maybe a promise. We'll wrap any reads of the tag variable in a
fork
call.Child
If a child returns an async value, it should return a promise.
Synchronously returning a Promise
We don't want to unwrap a promise that wasn't actually awaited, so we might want to have a custom promise wrapper and a custom
fork
that:fork
DOM Output
Parent
The parent will create a
source
to represent the tag variable and assign it to the child's scope insetup
:setTagVar
is a new runtime function that should look something likeChild
The child will add a special
tagVarSignal
dependency to whatever signal is returnedThis signal will look something like
Resuming
AccessorChars.TAG_VARIABLE
in its scopeAdditional consideration/optimization
We may not need to bind the signal that is passed to the child. When rendered client-side, the parent scope was being stored at
scope._
until #114, so if we re-attached the parent (something that's probably going to be necessary for cleanup anyways), we could just pass that intagVarSignal
instead ofnull
and relying on it being bound.However, this means that we need to ensure that the parent is serialized, which is slightly more involved than the above plan for resuming, but it does mean no additional object would need to be created for tag variables:
bindSignal
which creates a new object and 3 closures.The text was updated successfully, but these errors were encountered: