Skip to content
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

docs(resumability): description of non serializable entities #2124

Merged
merged 3 commits into from
Nov 14, 2022
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
11 changes: 8 additions & 3 deletions packages/docs/src/routes/docs/concepts/resumable/index.mdx
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
---
title: Resumable
contributors:
- voluntadpear
- RATIU5
- adamdbradley
---
Expand Down Expand Up @@ -83,13 +84,17 @@ Limitations of JSON which Qwik solves:
- JSON produces DAG. DAG stands for Directed Acyclic Graph, which means that the object which is being serialized can't have circular references. This is a big limitation because the application state is often circular. Qwik ensures that when the graph of objects gets serialized, the circular references get properly saved and then restored.
- JSON can't serialize some object types. For example, DOM references, Dates, etc... Qwik serialization format ensures that such objects can correctly be serialized and restored. Here is a list of types that can be serialized with Qwik:
- DOM references
- Dates (not yet implemented)
- Function closures (if wrapped in QRL).
- Promises
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well technically, promises are wrapped inside of "resources", so I think this should probably come with this disclaimer

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @shairez! I've added a link to the resources doc from this bit

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I would add something like

Promises (wrapped in "Resources" which is the link)

It'll make it more explicit IMO

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My doubt is that although the standard is to wrap promises under resources, it is technically possible to have a promise serialized without it, as can be seen in the revised serialization example: https://qwik.builder.io/docs/cheat/serialization/, that works correctly.

What do you think? If it would serve as a way to encourage people to always use useResource for promises regardless, I can word it as you suggested. Let me know 🙂

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's bring in the big guns... @manucorporat what do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

promises can be serialized in isolation, as long as they are resolved

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @manucorporat

  1. What do you mean by "in isolation"?
  2. Do you think it's a good idea to have a disclaimer about it in this doc?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think it's ok! i meant that a promise can be serialized without involving a resource, but it's good we put a reference there, they are mostly used together

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool thanks
merging

- Function closures (if wrapped in QRL)
- Dates
- `URL` objects
- `Map` and `Set` instances

Limitations of JSON that Qwik does not solve:

- Serialization of classes (`instanceof` and prototype)
- Serialization of `Promise`s, Streams, etc...
- Although some built-in classes, such as [Date](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date), [URL](https://developer.mozilla.org/en-US/docs/Web/API/URL), [Map](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map), [Set](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set) are supported.
- Serialization of Streams, etc...

### Writing applications with serializability in mind

Expand Down