-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
feat: explain the limitations of serialization #10944
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
base: main
Are you sure you want to change the base?
Changes from all commits
a66a37b
487a928
baad915
f4bfc8d
b791f45
7612c12
da57320
45eeae1
c47ed90
28d2818
a309d6b
e701c6b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -33,6 +33,15 @@ const avatarURL = await getUserAvatar(userSession); | |
--- | ||
<img alt="User avatar" src={avatarURL} /> | ||
``` | ||
:::caution[Server Island Prop Limitations] | ||
You can pass a function as a prop to a server island component, but this only works during server rendering. If you try to use the function in a hydrated component (for example, as an event handler), an error will occur. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This example seems weird to me. Server islands are not hydrated (at least not in the sense we use anywhere else in the docs for that word, it doesn't add handlers and bindings for interactivity to existing DOM nodes). They get replaced with the content of a separate request when loaded. The fallback/original content doesn't require any hydration and neither does the code after the swap. After the swap there isn't even any JS related to the server island in the document, contrary to hydration, which is also a win for server island, and might give people the idea that server islands are heavier on their site than it really is. |
||
|
||
This is because functions cannot be _serialized_ (transferred from the server to the client) by Astro. Objects with circular references are also not serializable. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this should have the same wording regarding serialization as the client islands. Even more so here to not say that the limitation is regarding sharing information with the client because that is an implementation detail. It could send the information between instances of the server (which might remove some other limitations we currently have) and it would have the same problem. |
||
|
||
Props provided to hydrated components must be serializable. The following prop types are supported: | ||
`plain object`, `number`, `string`, `Array`, `Map`, `Set`, `RegExp`, `Date`, `BigInt`, `URL`, `Uint8Array`, `Uint16Array`, `Uint32Array`, and `Infinity` | ||
::: | ||
|
||
|
||
## Server island fallback content | ||
|
||
|
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.
Server islands are always server rendered. That is their purpose, make something server rendered even on a statically pre-rendered page. So this seems a bit unhelpful.
Functions can be passed as props while on the server, they can't be passed to the components marked with
server:defer
. Meaning you can pass functions around on a server island, but never to a server island.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.
Hey @Fryuni! Thanks again. I'll steal some of what you wrote here as it was very helpful for me to better understand the limitation, specifically this point:
Meaning you can pass functions around on a server island, but never to a server island.