---
# System prepended metadata

title: '`QObject` brainstorming'

---

# `QObject` brainstorming

## Goal

Design a *minimal* object persistence model. 

## Motivations

- `Record` seems to be too specific to persistence and we would prefer something which is more low-level on top of which something like `Record` could be built.

## Constraints

- Need to be able to pass structured data between components 

## Mental Model

- `QObject` is the primitive which contains
  - UUID
  - Ref/Transient
  - Data
- Components are roots for serialization
- Elements act as WeakMap keys to retrieve the Objects and allow for GC


## Brainstorming

```htmlembedded=
<my-component prop-a=":1234" q:obj="1234 87349 923487">
```

-`prop-a=":1234"`: `MyComponent` has `propA` which is bound to object with UUID 1234.
- `q:obj="1234 ..."`: contains a list of objects associated with this ref.

Serialization process would start with components and follow what they are bound to. There is no central repository of components as with `QRecord`. 

At dehydration time select all components walk their `QObject`s and serialize them at the end of the `<body>`. 

References:
- Root nodes are represented by the components/HTMLElement.
- Points to Map of `QObject`s.
- HTMLElement must have all of the objects listed in HTML under `q:obj` so that it is easy to invalidate the components when a change in object is detected.
  - each HTMLElement has `q:obj` as well as `Map` to get objs. The two are kept in sync. (Maybe we can get rid of map and just keep global map?/ Maybe component is just `QObject` and the first uuid in `q:obj`)
    - `children': This requires that `QObject` has `children` so that it can notify them when it goes to zero. (Alternative is to have a weakmap? no beacause we still need to release it from the map.)


PROBLEM: How do you keep objs in sync across components? Need global map? In which case how do you prevent memory leak?
- SOLUTION: Global map. But now we have a problem with mem leak.
  - SOLUTION: When `QObject` are added/removed than we find parents and add/remove them. When count =0 remove from map. Treat components as roots and only remove them when DOM goes away.

Speculation (confirmed)
- Each `QObject` must have refs to:
  - `parents`: Needed to notify the components that a `QObject` got added or removed.
    - Maybe it is not `parents`, but rather `root`s (as in component roots).
  - `children`: Efficient way to visit all children when the object's ref goes to zero. Then all of the children need to be cleared (making decrementing their ref, which may cause them to be released)


## FAQ:
Why do we need `QObject`s to auto-detect changes.
- If objects did not how would one know which components to re-render? In react one just re-renders from root. It is needed for the purposes of depedency tracking