dinou

v3.0.2

Published

3 hours ago

Dinou is a modern React 19 framework with React Server Components, Server Functions, and streaming SSR.

Downloads

611

0High
0Medium
0Low

roggc

react react-19 react-server-components rsc react-server-functions framework react-framework esbuild rollup webpack ssr streaming dinou

Dinou: A React 19 Framework

Dinou is a React 19 framework. "dinou" means 19 in Catalan. You can create a Dinou app by running the command npx create-dinou@latest my-app.

Or you can create one by yourself with the following steps:

Create an npm project (npm init -y)
Install dependencies (npm i react react-dom dinou)
Create scripts in package.json for convenience:
- "dev": "dinou dev"
- "build": "dinou build"
- "start": "dinou start"
- "eject": "dinou eject"

Create an src folder with a page.jsx (or .tsx)

"use client";

export default function Page() {
  return <>hi world!</>;
}

Run npm run dev (or npx dinou dev) to see the page in action in your browser.
If you run npm run eject (or npx dinou eject), Dinou will be ejected and copied to your root project folder, so you can customize it.

Dinou main features are:

File-based routing system.
SSR (Server Side Rendering)
SSG (Static Site Generation)
ISR (Incremental Static Regeneration)
Pure React 19: Server Functions, Suspense, Server Components, ...
TypeScript or JavaScript
Full control and customization through the command npm run eject (npx dinou eject)
Support for the use of .css, .module.css, and Tailwind.css
Support for the use of images in your components (.png, .jpeg, .jpg, .gif, .svg, .webp)
Support for the use of an import alias in tsconfig.json or jsconfig.json file.
Error handling with error.tsx pages, differentiating behaviour in production and in development.

Routing system, layouts, pages, not found pages, ...

Routes are defined by defining a page.tsx file (or .jsx) in a folder.
Route "/" corresponds to the src folder.
You can define layouts and nested layouts by defining a layout.tsx (or .jsx) file in a folder. A layout file found in a folder wraps a layout file found in a more nested folder, and finally composition of all layouts found in a route hierarchy wraps the page component or not_found component.
You can define not found pages by defining not_found.tsx (or .jsx) file in a folder. If more than a not_found.tsx file is found in a route hierarchy, the more nested one will be used.
If you don't want a page to be applied layouts define a no_layout file (without extension) in the same folder. A no_layout file, if present, also applies to the not_found file if present in the same folder. There exists also a no_layout_not_found file if you don't want a not_found file to be applied layouts but you do in page component.
reset_layout file (without extension) if present in the same folder as a layout.tsx file, will ignore previous layouts in the layout hierarchy.
If found any error.tsx (or .jsx) page in the route hierarchy, the more nested one will be rendered in case of error in the page. Layouts are also applied to error pages if no no_layout or no_layout_error files (without extension) exists in the folder where error.tsx is defined.

page_functions.ts (or `.tsx`, `.js`, `.jsx`)

page_functions.ts is a file for defining four diferent possible functions. These are:

getProps: a function to fetch data in the server and pass this data as props to the page component and the root layout (if exists).

// src/dynamic/[name]/page_functions.ts
export async function getProps(
  params: { name: string },
  query: Record<string, string>,
  cookies: Record<string, string>
) {
  const data = await new Promise<string>((r) =>
    setTimeout(() => r(`Hello ${params.name}`), 2000)
  );

  return { page: { data }, layout: { title: data } };
}

getStaticPaths: function to get the values of a dynamic param in the route for which SSG will be applied. Fetching data in the server with getProps or within the body of a Server Component increases the FCP (First Contentful Paint), that is, when the user sees something on the screen, when rendering dynamically, that is, on the fly. So this technique must only be used if acompanied by SSG (Static Site Generation). This means that at build time the data is fetched so when a user requests a page statically generated at build time he/she hasn't to wait for the data to be fetched on the server. This is good for SEO, when data is necessary for SEO.
```
// src/dynamic/[name]/page_functions.ts
export async function getProps(
  params: { name: string },
  query: Record<string, string>,
  cookies: Record<string, string>
) {
  const data = await new Promise<string>((r) =>
    setTimeout(() => r(`Hello ${params.name}`), 2000)
  );

  return { page: { data }, layout: { title: data } };
}

export function getStaticPaths() {
  return ["albert", "johan", "roger", "alex"];
}
```
dynamic: this function is for when we want the page to be rendered dynamically, bypassing a possible statically generated file. It must return true to render a page dynamically. Otherwise the rendering system will use the statically generated file if exists.
```
export function dynamic() {
  return true;
}
```
revalidate: this function is for when we want to revalidate data fetched in SSG.
```
export function revalidate() {
  return 60000; // ms
}
```

Fetching data with `Suspense`

We have already seen that data can be fetched on the server with the getProps function or within the body of a Server Component, but this needs to be accompanied of a mechanism of SSG of the page/s to not increase the FCP.

There is an alternative that do not increase FCP even when rendering dynamically and that is to use Suspense for data fetching, either in the server (in a Server Component) and in the client (in a Client Component).

// src/posts/post.tsx
"use client";

export type PostType = {
  title: string;
  content: string;
};

export default function Post({ post }: { post: PostType }) {
  return (
    <>
      <h1>{post.title}</h1>
      <div>{post.content}</div>
    </>
  );
}

// src/posts/get-post.tsx
"use server";

import Post from "./post";
import type { PostType } from "./post";

export async function getPost() {
  const post = await new Promise<PostType>((r) =>
    setTimeout(
      () => r({ title: "Post Title", content: "Post content" }),
      1000
    )
  );

  return <Post post={post} />;
}

// src/posts/page.tsx
"use client";

import Suspense from "react-enhanced-suspense";
import { getPost } from "./get-post";

export default function Page() {
  return (
    <>
      <Suspense fallback={<div>Loading...</div>} resourceId="get-post">
        {() => getPost()}
      </Suspense>
    </>
  );
}

In Client Components, the resourceId prop together with passing a function to the children prop of Suspense from react-enhanced-suspense makes the promise returned by the Server Function stable between re-renders, and it is only reinvoked the Server Function whenever the resourceId changes.

The same can be done with page.tsx being a Server Component. In that case we would not use the resourceId prop and we will call directly the Server Function:

// src/posts/page.tsx
import Suspense from "react-enhanced-suspense";
import { getPost } from "./get-post";

export default async function Page({ data }: { data: string }) {
  return (
    <>
      <Suspense fallback={<div>Loading...</div>}>{getPost()}</Suspense>
    </>
  );
}

Suspense from react-enhanced-suspense is React's Suspense when no extra prop is used.

Fetching data in the server without `Suspense` (revisited)

This option is useful for SSG (Static Site Generated) pages. When used with dynamic rendering (no SSG) it increases the FCP (First Contentful Paint), that is, when the user sees something rendered on the page.

The recommended way to use it is with page.tsx being a Client Component and defining a page_functions.ts with getProps function defined and exported. The other option is to use a Server Component for page.tsx instead of a Client Component and do the fetch in the body of the Server Component (async function) or, what is equivalent, use the getProps function defined and exported in page_functions.ts too.

Pages in static routes (e.g. /some/route) are statically generated (SSG) if no dynamic function returning true is defined and exported in a page_functions.ts. Therefore, statically generated pages for static routes will be served if no query params are present in the request. If there are query params pages will be served dynamically.

Pages in dynamic routes (e.g. /[id], or /[[id]], [...id], [[...id]]) are statically generated (SSG) if no dynamic function returning true is defined and exported in a page_functions.ts, for those values of the dynamic param returned by function getStaticPaths defined and exported in page_functions.ts. Again, if query params are used in the request of the page, then it will be rendered dynamically, affecting the FCP (increasing it). Or those requests using dynamic params not returned by getStaticPaths will also be rendered dynamically.

Example with optional catch-all dynamic route:

// src/catch-all-optional/[[..names]]/page.tsx
"use client";

export default function Page({
  params: { names },
  data,
}: {
  params: { names: string[] };
  data: string;
}) {
  return (
    <>
      {names}
      {data}
    </>
  );
}

// src/catch-all-optional/[[..names]]/page_functions.ts
export async function getProps(
  params: { names: string[] },
  query: Record<string, string>,
  cookies: Record<string, string>
) {
  const data = await new Promise<string>((r) =>
    setTimeout(() => r(`Hello ${params.names.join(",")}`), 2000)
  );

  return { page: { data }, layout: { title: data } };
}

export function getStaticPaths() {
  return [["albert"], ["johan"], ["roger"], ["alex"], ["albert", "johan"]];
}

In this case statically generated routes will be /catch-all-optional, /catch-all-optional/albert, /catch-all-optional/johan, /catch-all-optional/roger, /catch-all-optional/alex, and /catch-all-optional/albert/johan. Any other route starting by /catch-all-optional/* will be rendered dynamically, increasing the FCP by 2 secs (2000 ms) in this particular case.