docs: show how to read Harper data from the React SSR entry#106
Conversation
The React SSR templates' entry-server told developers to use the request URL
"to drive routing/data loading per request" but showed no example, leaving them
to guess how — or whether — they can reach Harper data during SSR. That gap led
to workarounds (e.g. fetching the app's own REST API over loopback) and to the
mistaken belief that the Vite-loaded SSR entry can't see Harper's globals.
- entry-server.{jsx,tsx}: document the native pattern — make `render` async and
`import { tables } from 'harper'` to query a table. `tables` is the same live,
process-wide registry available everywhere in Harper; the SSR entry reaches it
because Harper symlinks node_modules/harper to the running install.
- vite.config.{js,ts}: add `ssr.external: ['harper']` so that import resolves to
the running runtime instead of being bundled (symlinked deps aren't reliably
auto-externalized for SSR).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the React and React-TS SSR templates to support server-side rendering with data fetched directly from Harper. It configures Vite to keep harper external during SSR and adds documentation/examples in the server entry files. The reviewer suggested adding notes to the code examples in both templates to clarify that the App component needs to be updated to accept the product prop, preventing potential TypeScript compilation errors or non-functional code.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
The data-loading example renders `<App product={product} />`, but the template's
App component takes no props — copy-pasting it as-is would cause a TS error (and
a silently-ignored prop in JS). Add a one-line note in each example.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
🎉 This PR is included in version 1.10.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
kriszyp
left a comment
kriszyp
left a comment
There was a problem hiding this comment.
Accurate SSR data-read example, consistent with the process-wide-singleton docs. Approving. — Claude (Opus 4.8)
2 participants
Why
The React SSR templates ship an
entry-serverwhose comment says to use the request URL "to drive routing/data loading per request" — but gives no example of how. With emptyschemas//resources/and no data-flow example, a developer reaching the Vite-loaded SSR entry has nothing to go on, and can reasonably (but wrongly) conclude they can't access Harper data there. That leads to workarounds like fetching the app's own REST API over loopback, or assuming the SSR entry doesn't get Harper's globals.In reality,
tables/databasesare live process-wide objects, andnode_modules/harperis symlinked to the running install — soimport { tables } from 'harper'works in the SSR entry.What
Applied to both
template-react-ssrandtemplate-react-ts-ssr:entry-server.{jsx,tsx}— expanded the doc comment to show the native pattern: makerenderasync andimport { tables } from 'harper'to query a table, rendering with data already in place (no client fetch).vite.config.{js,ts}— addedssr: { external: ['harper'] }with an explanatory comment. Symlinked deps aren't reliably auto-externalized for SSR, so this is what makesimport { tables } from 'harper'resolve to the running runtime instead of being bundled.Both changes are additive (comment + config); the default scaffold still builds and runs unchanged.
🤖 Generated with Claude Code