Tegonal React Router Starters

This project contains various React Router starters, each tailored for different use cases. The goal is to provide a solid foundation for building applications with React Router, showcasing best practices and efficient patterns.

All starters are designed to be easily extensible and customizable, allowing developers to adapt them to their specific needs. The starters are built with TypeScript and utilize the latest features of React Router.

Available Starters

• ssr-daisyui: A starter template for server-side rendering (SSR) with DaisyUI components.
• csr-daisyui: A starter template for client-side rendering (CSR) with DaisyUI components.

Getting Started

To get started with any of the starters, use create-react-router and reference the starter template using its location on GitHub like so:

# ssr-daisyui
npx create-react-router@latest --template https://github.com/tegonal/react-router-templates/tree/main/packages/ssr-daisyui

# csr-daisyui
npx create-react-router@latest --template https://github.com/tegonal/react-router-templates/tree/main/packages/csr-daisyui

Then, follow the instructions of create-react-router to set up your project.

Prerequisites: Node.js ≥ 24 and Yarn 4. Run corepack enable once (Corepack ships with Node) — it then uses the Yarn version pinned by the project automatically, so you don't need to install Yarn yourself.

To get the project up and running, navigate to the project directory that was just created and run:

yarn install # to install all dependencies
yarn up # to update the dependencies
yarn dev # to start the development server

When to use which?

Arguments that can help you decide between SSR and CSR:

SSR (Server-Side Rendering)

• SEO: If your application has public content and needs to be indexed by search engines, SSR might be the better choice.
• Performance: SSR can improve the initial load time of your application, especially for content-heavy pages.
• User Experience: SSR can provide a better user experience by reducing the time to first paint (TTFP) and time to interactive (TTI).
• Accessibility: SSR can improve accessibility for users with slow internet connections or older devices.
• Progressive Enhancement: SSR can be a good choice if you want to ensure that your application works even if JavaScript is disabled or not fully supported. React Router can, if thoughtfully implemented, create pages that work without JavaScript unless heavy interaction is required.
• Content Management Systems (CMS): If your application is built on a CMS, SSR can help to deliver content faster and improve SEO.
• Integrated APIs or Facades: An SSR approach can be useful if you need simple APIs or facades that would otherwiese either cause complex client side code or a separate API server.

CSR (Client-Side Rendering)

• Interactivity: If your application is highly interactive and requires a lot of client-side rendering, CSR may be a better choice.
• Development Speed: CSR can be faster to develop and deploy, especially for smaller applications or prototypes.
• Simplicity: If your application is simple and doesn't require complex routing or state management, CSR may be a better choice.
• Cost: CSR can be cheaper to host and maintain, especially for smaller applications or prototypes as they can be served statically.
• Development Experience: If you are more comfortable with client-side rendering and have experience with it, CSR may be a better choice.
• Ecosystem: If you are already using a lot of client-side libraries and frameworks, switching to SSR might require a bit of mental gymnastics.

In the end, both SSR and CSR have their pros and cons and both approaches can be used to create the same application and features. If you feel more comfortable with one approach over the other, this could be an additional argument to base a decision on. As always, it depends.

Components & styling

Both starters use DaisyUI for styling and ship with Base UI for headless, accessible behavior. The convention:

• Simple, presentational components (buttons, cards, badges, inputs) — just use DaisyUI classes.
• Complex, interactive components (dropdowns, dialogs, menus, selects, popovers, tabs, tooltips) — build on Base UI headless components and style them with DaisyUI classes and theme tokens. Base UI provides focus management, keyboard navigation and ARIA; DaisyUI provides the look. Avoid DaisyUI's structural container classes (modal, dropdown, collapse) on Base UI components — use Tailwind utilities and theme tokens instead.

Contributing

We welcome contributions to this project! If you have suggestions, improvements, or bug fixes, please feel free to open an issue or submit a pull request.