Repository navigation
Conversation
|
@omridevk is attempting to deploy a commit to the NuxtLabs Team on Vercel. A member of the Team first needs to authorize it. |
|
👁️🗨️ Review this pull request with grouped, summarized diffs at: raw result💭 analyzed by {
"headSha": "47ca623e7bb9c34afa1268752c109511c0160d98",
"result": {
"overallSummary": "Fixes a hydration bug where VueUse's `useScreenSafeArea` injected safe-area CSS variables onto `<html>`, breaking SSR hosts. The fix introduces a custom `useSafeArea` composable scoped to the Dock's own anchor element, with the inset variables now defined locally in `style.css`.",
"groups": [
{
"key": "dock-safe-area-fix",
"label": "Dock safe-area fix",
"summary": "Replaces VueUse's `useScreenSafeArea` (which always writes CSS variables onto `<html>`) with a local `useSafeArea` composable that reads safe-area inset variables scoped to a given element, avoiding hydration mismatches on SSR hosts. The inset variables themselves are now defined in `style.css` instead of being injected globally.",
"category": "ui",
"filePaths": [
"packages/hub-ui/src/client/style.css",
"packages/hub-ui/src/client/components/dock/Dock.vue",
"packages/hub-ui/src/client/utils/useSafeArea.ts"
],
"fileNotes": [
{
"path": "packages/hub-ui/src/client/utils/useSafeArea.ts",
"text": "New composable ported from VueUse's useScreenSafeArea, but scoped to a target element instead of mutating `<html>` directly."
},
{
"path": "packages/hub-ui/src/client/components/dock/Dock.vue",
"text": "Dock now computes safe-area values from its own anchor element rather than the document root, and `toNumber` uses `Number.parseFloat` instead of unary `+` to correctly parse CSS length strings like '16px'."
}
]
}
],
"schemaVersion": 1,
"source": "llm",
"generatedAt": "2026-11-04T20:41:13.789Z",
"model": "vercel-ai-gateway/anthropic/claude-sonnet-5",
"locale": "en"
}
} |
|
|
||
| /** | ||
| * Ported from VueUse's `useScreenSafeArea` for now: it always sets its CSS variables on | ||
| * `<html>` and has no option for a custom element, which breaks hydration on SSR hosts. |
There was a problem hiding this comment.
@antfu I wasn't sure about this part, so I added this "port" to suggest whether this addition should be added to VueUse, didn't want to make too many decisions, do let me know if this is even a good direction, or:
- Port back the fix to VueUse
- Remove the safeArea usage all together? probably not
- Close PR and accept the warning and have the users manually import the Dock
There was a problem hiding this comment.
🟡 Changes recommended
Safe-area values retain their px units and are converted to zero by toNumber(), allowing the dock and its panel to overlap a notch or home indicator.
1 open issue
What changed in this PR
This PR addresses #482 by replacing the dock’s safe-area reader so it no longer adds inline styles to <html>, avoiding React SSR hydration mismatches.
Changes:
- Add a target-based
useSafeAreautility that reads insets on mount and resize. - Define safe-area CSS variables in the hub UI stylesheet.
- Connect the dock’s anchor element to the new utility.
| File | Description |
|---|---|
packages/hub-ui/src/client/utils/useSafeArea.ts |
Adds element-scoped safe-area measurement. |
packages/hub-ui/src/client/style.css |
Defines four safe-area inset variables. |
packages/hub-ui/src/client/components/dock/Dock.vue |
Replaces useScreenSafeArea with the anchor-based utility. |
Review effort: Balanced
| top.value = style.getPropertyValue('--devframes-safe-area-top') | ||
| right.value = style.getPropertyValue('--devframes-safe-area-right') | ||
| bottom.value = style.getPropertyValue('--devframes-safe-area-bottom') | ||
| left.value = style.getPropertyValue('--devframes-safe-area-left') |
useScreenSafeArea sets its CSS variables on <html>, which React SSR hosts hydrate themselves, so loading the dock logs a hydration mismatch. Port it as useSafeArea(target): the variables live in the dock stylesheet :host and are read back from the dock anchor. Also parse the insets with parseFloat, since values like "34px" made the unary plus return NaN, so insets were 0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
0fb86d4 to
47ca623
Compare

fix #482
(Disclaimer, code was written with Claude, but was meticulously reviewed by a human being or so I claim to be :P )