Skip to content

Commit 9db7ca4

Browse files
authored
docs: fixed up some types (#7498)
1 parent edb5516 commit 9db7ca4

File tree

1 file changed

+2
-2
lines changed
  • packages/docs/src/routes/docs/labs/devtools

1 file changed

+2
-2
lines changed

Diff for: packages/docs/src/routes/docs/labs/devtools/index.mdx

+2-2
Original file line numberDiff line numberDiff line change
@@ -32,8 +32,8 @@ Most of the resulting output should be self explanatory. But we provide few high
3232
- `refs`: A set of `QRef` objects.
3333
- `sub`: A set of `QSubscription` objects.
3434
- `QContext`: Represents a state which Qwik had to serialize for a given component. This includes `props` for the component as well as a set of `Task` objects which the component may need to execute.
35-
- `QRef`: If an element has a listener, than a `QRef` collects the listeners as well as any objects which the listener may have captured.
35+
- `QRef`: If an element has a listener, then a `QRef` collects the listeners as well as any objects which the listener may have captured.
3636

3737
The way to think about Qwik serialization is that Qwik wants to serialize minimal amount of information. For this reason it only serializes objects which are reachable from either `QContext` or from `QRef`. This means that if you have an object which is not reachable from either of these two, then it will not be serialized. This is a good thing, because it means that Qwik will not serialize the entire application state, but only the state which is reachable from the component which is being rendered.
3838

39-
The flip side is that if you see an object being serialized and you think it should not be you can trace it backwards to see why it is being serialized. For this purpose all objects include a `__backRef` property which points to the object which is causing any object to be retained. By tracing the objects references back to their roots (which should be `QContext` or `QRef`) we can determine which a particular object is being serialized. Similarly we can see if we can refactor our code to prevent serialization of said object.
39+
The flip side is that if you see an object being serialized and you think it should not be you can trace it backwards to see why it is being serialized. For this purpose all objects include a `__backRef` property which points to the object which is causing any object to be retained. By tracing the objects references back to their roots (which should be `QContext` or `QRef`) we can determine because of which one a particular object is being serialized. Similarly we can see if we can refactor our code to prevent serialization of said object.

0 commit comments

Comments
 (0)