A minimal, React server rendering "framework" for web pages.
A minimal, React server rendering "framework" for web pages.
Imagine RSC without client components (yet).
yarn add @srvr-rndr/react @srvr-rndr/cli
And react, react-dom...
index.tsx
file with the following contents:import React from 'react'
import {
AppProps,
FallbackProps,
getReactRequestHandler,
} from '@srvr-rndr/react'
function App({ url }: AppProps) {
return (
<div>
<marquee>App being served from: {url}</marquee>
</div>
)
}
function Fallback({ error }: FallbackProps) {
return <pre>{JSON.stringify(error, null, 2)}</pre>
}
export default function handler(request: Request): Promise<Response> {
return getReactRequestHandler({
App,
Fallback,
})(request)
}
In your package.json:
{
"scripts": {
"build": "srvr-rndr build"
}
}
Add a vercel.json
file with the following contents:
{
"buildCommand": "yarn build"
}
Run vercel build
and then vercel deploy --prebuilt
!
This repo is using the following:
Deno
: ^1.35.0Yarn
: ^3.5.0Turbo
: 1.10.7To get started, clone the repo then run yarn
to install dependencies and setup
the monorepo.
From there you can run the tasks across all workspaced via deno task <task>
,
the current available tasks are:
lint
deno task lint
, will run lints across all workspacestest
deno task test
, will run tests across all workspacesformat
deno task format
, will format all files within the monorepoformat:check
deno task format:check
, will check the format of the files in thebuild
deno task build -- <version-number>
, will run builds acroass all<version-number>
is required, and generates the latest version of theMeaning the framework will strive to leverage globals that are web-standard, for
example using native Request
and Response
built-ins, or using native
globalThis.fetch
etc.
My hope is that the framework can be widely used because of this decision.
It may seem odd to have performance be the fourth goal, but I'd rather have a nice to use framework than something super brittle.
I want it to:
While the intent with this project is to create a relatively un-opinionated framework, it does have a few opinions that are documented here.
app/
directoryExample directory structure:
your-app/
app/
index.tsx
Feature.tsx
utils.ts
Most frameworks force separate files for different routes, Srvr Rndr does the opposite. This is mainly because most of the application should live on the server, and only a few features will run on the client.
Several frameworks have combined config of features/routes within the source code of the feature. This has some nice benefits but comes with the trade off of being either oddly constraining, or includes additional complexity within the framework itself.
At the moment I'm leaning towards maintaining config in a central place, that can easily be imported / resolved without a transform at the framework level.
This might be a surprising thing to find on a project readme, but at the moment I feel like the project wouldn't be suitable for any and all web applications, instead I think it best serves fairly "simple" web pages (think a blog, or a documentation site).
If you're building an e-commerce experience, you may want to consider alternative solutions like Next.js!