Skip to content

context#459

Open
ruchI9897 wants to merge 52 commits into
mainfrom
context
Open

context#459
ruchI9897 wants to merge 52 commits into
mainfrom
context

Conversation

@ruchI9897

Copy link
Copy Markdown
Contributor

No description provided.

@vercel

vercel Bot commented Apr 27, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
developer-docs Ready Ready Preview, Comment Jul 20, 2026 6:24am

Request Review

@snyk-io

snyk-io Bot commented Apr 27, 2026

Copy link
Copy Markdown

Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues
Licenses 0 0 0 0 0 issues
Code Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

Without matching wrapRootElement in both files, the SSR tree (no
FloatingAssistantProvider wrapper) differed from the client tree
(with wrapper), causing React hydration errors #418/#423 that broke
all doc pages on deployment.

FloatingAssistantProvider is now SSR-safe: all state initializes with
static defaults; sessionStorage/browser APIs are only read in useEffect.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
wrapRootElement in gatsby-browser.js was the root cause of hydration
errors #418/#423. Gatsby SSRs every page without the wrapper but the
client added it, creating a tree structure mismatch.

New approach: onClientEntry creates a separate div appended to body
and mounts FloatingAssistantProvider + FloatingAssistant via
ReactDOM.createRoot — completely outside Gatsby's tree. Gatsby never
sees or hydrates this subtree, so there is no server/client mismatch.

Document/index.tsx no longer uses useFloatingAssistant context —
it fires the existing 'spotter-code-ask' CustomEvent instead, which
the standalone FloatingAssistant already listens for.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@thoughtspot/radiant-react reads `window` at module load time.
Top-level require() in gatsby-browser.js caused it to be evaluated
during Gatsby's SSR build where window doesn't exist, corrupting
hydration for all pages.

Dynamic import() inside onClientEntry ensures radiant-react and
FloatingAssistant are only loaded in the browser, never during SSR.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Restore .npmrc trailing newline (matches main)
- Remove unnecessary .scss module declaration from src/index.d.ts
- Move useState declarations before useEffect in FloatingAssistantContext

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Comment thread src/components/FloatingAssistant/helpers.ts Fixed
ruchI9897 and others added 2 commits July 20, 2026 11:13
…nescaping'

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants