@barefootjs/cli 0.33.6 → 0.35.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/docs/core/components/portals.md +7 -0
- package/dist/index.js +479 -291
- package/package.json +5 -5
|
@@ -125,6 +125,13 @@ const handleMount = (el: HTMLElement) => {
|
|
|
125
125
|
|
|
126
126
|
`bf-po` on the moved element lets scoped queries from the owner still find it.
|
|
127
127
|
|
|
128
|
+
`ownerScope` also fixes *where* the element ends up among the container's children. Portal content is always appended to the container immediately — it is in the document from the moment `createPortal` returns, so a `ref` callback can measure it (`offsetWidth`, `getBoundingClientRect()`) in the same tick — and its position settles once its owner is connected:
|
|
129
|
+
|
|
130
|
+
- Owner already connected (hydration — the SSR markup is in the document before `init` runs), or no `ownerScope` given: a single append, at the container's end.
|
|
131
|
+
- Owner not yet connected (a client-side mount — the component's `init`, and so the `ref` callback, runs before whoever called `createComponent()` appends the root): once the owner connects, the element is re-appended, which moves it to the container's end. Pending portals move in creation order, before the next paint.
|
|
132
|
+
|
|
133
|
+
Both construction paths therefore land on the same `document.body` child order — the component root first, then its portals in the order they were created — which decides paint order between overlays with equal `z-index`, focus traversal, and `querySelector` results.
|
|
134
|
+
|
|
128
135
|
|
|
129
136
|
## Dialog Example
|
|
130
137
|
|