Now embed templates can define simplified version of our styles which is
useful for radix components and as AI output.
```
styles: [
{
property: 'backgroundColor',
value: { type: 'keyword', value: 'red' }
}
]
```
Ref https://github.com/webstudio-is/webstudio-builder/pull/1516
Here added new utility "tree template" to describe children in component
meta and generate instances from it while inserting.
Added simple template to form component as example.
## Description
Made handshake between canvas and builder.
Now publish actions are delayed in local array until handshake message
from destination is received
Switched on hydrateRoot to enable concurrent mode
unstable_batchedUpdates are removed
## Steps for reproduction
## Code Review
- [ ] hi @kof, I need you to do
- conceptual review (architecture, feature-correctness)
- detailed review (read every line)
- test it on preview
## Before requesting a review
- [ ] made a self-review
- [ ] added inline comments where things may be not obvious (the "why",
not "what")
## Before merging
- [ ] tested locally and on preview environment (preview dev login:
5de6)
- [ ] updated [test
cases](https://github.com/webstudio-is/webstudio-builder/blob/main/apps/builder/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env.example`
and the `builder/env-check.js` if mandatory
## Description
Reduces amount of renders from 6 to 2 on addding/deleting instances
Reduction to 1 render is impossible in our current architecture as
following situation happens.
On add node, we set selectedInstanceSelectorStore from the builder, what
cause
In the canvas "SelectedInstanceConnector" sets computed styles etc and
sync back. Both are causing double rendering.
Can be avoided in the future allowing to set store from the builder in a
canvas.
## Steps for reproduction
1. click button
2. expect xyz
## Code Review
- [ ] hi @kof, I need you to do
- conceptual review (architecture, feature-correctness)
- detailed review (read every line)
- test it on preview
## Before requesting a review
- [ ] made a self-review
- [ ] added inline comments where things may be not obvious (the "why",
not "what")
## Before merging
- [ ] tested locally and on preview environment (preview dev login:
5de6)
- [ ] updated [test
cases](https://github.com/webstudio-is/webstudio-builder/blob/main/apps/builder/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env.example`
and the `builder/env-check.js` if mandatory
Ref https://github.com/webstudio-is/webstudio-builder/issues/1116
Slot is copy pastable part of the tree which is always in sync. Kinda
like primitive components.
The idea is the following. Slot is copy pasted as any other instance
though its children are preserved as is without cloning with new ids.
This lead to the problem with multiple slot children. While copy paste
they are preserved as is though when add new child to slot, the other
instance of it will not get new child.
To workaround this we add another Fragment component which groups all
children into single one and new children are always reflected in all
slot copies.
- in many places root check can be replaced with selector.length === 1
- reparent and insert utilities now accept selectors
- findClosestDroppableTarget output end instead of last index and always
fallback to root
With slots there can be same ids in one tree so we need new way to
address instances. Here I propose the list from target instance to the
root.
Now instead of computing parents by normalized tree (one instance of
slot can have many parents) we just access already computed list from
rendered tree.
This address can be computed when user click in dom which can be
traversed or it can be passed top-down with props.
The main con of this approach is collaboration. Reparanted instances on
by one user makes "selected address" stale. Though we have similar
situation with single id when instance is deleted.
Isolated mode for slots/components will make this problem less
noticable.
Need to cleanup all page related data to prevent bloating project with
garbage data. Delete already prevent reloading so its safe to clear data
on client.
We found a bug a bug after release. Any instances changes on the page
erase instances of other pages.
Recently I migrated to normalized instances though didn't have time to
migrate utilities and just added patchInstancesMutable utility to
synchronize changes from denormalized rootInstance to normalized
instances.
Though after merging instances of all pages into single list this
synchronization started to clear instances not found in rootInstance.
To solve this I stopped clearing instances in patchInstancesMutable and
migrate delete instances utility to mutating normalized instances
directly.
Bogdan Chadkin