Animation

Motion One will be used to handle component transition

View Transitions API will be used between page transition

Tested Library / Functionality

UI

• Tailwind
• [] SCSS / Emotion
• [] Storybook
• [] jest(?)

State management

• [] zustand/vanilla (possible mess up qwik philosophy?)

Maintenance

• Husky

Backend Connection

• [] trpc
• [] Firebase
  • [] Auth
  • [] Hosting
  • [] Functions

Qwik App ⚡️

• Qwik Docs
• Discord
• Qwik Github
• @QwikDev
• Vite
• Partytown
• Mitosis
• Builder.io

---

Project Structure

Inside of you project, you'll see the following directories and files:

├── public/
│   └── ...
└── src/
    ├── components/
    │   └── ...
    └── routes/
        └── ...

• src/routes: Provides the directory based routing, which can include a hierarchy of layout.tsx layout files, and index.tsx files as the page. Additionally, index.ts files are endpoints. Please see the routing docs for more info.

• src/components: Recommended directory for components.

• public: Any static assets, like images, can be placed in the public directory. Please see the Vite public directory for more info.

Add Integrations

Use the npm run qwik add command to add other integrations. Some examples of integrations include as a Cloudflare, Netlify or Vercel server, and the Static Site Generator (SSG).

npm run qwik add

Development

Development mode uses Vite's development server. For Qwik during development, the dev command will also server-side render (SSR) the output. The client-side development modules loaded by the browser.

npm run dev

Note: during dev mode, Vite will request many JS files, which does not represent a Qwik production build.

Preview

The preview command will create a production build of the client modules, production build of src/entry.preview.tsx, and create a local server. The preview server is only for convenience to locally preview a production build, but it should not be used as a production server.

npm run preview

Production

The production build should generate the client and server modules by running both client and server build commands. Additionally, the build command will use Typescript run a type check on the source.

npm run build

Express Server

This app has a minimal Express server implementation. After running a full build, you can preview the build using the command:

npm run serve

Then visit http://localhost:8080/

Cloudflare Pages

Cloudflare's wrangler CLI can be used to preview a production build locally. To start a local server, run:

npm run serve

Then visit http://localhost:8787/

Deployments

Cloudflare Pages are deployable through their Git provider integrations.

If you don't already have an account, then create a Cloudflare account here. Next go to your dashboard and follow the Cloudflare Pages deployment guide.

Within the projects "Settings" for "Build and deployments", the "Build command" should be npm run build, and the "Build output directory" should be set to dist.

Function Invocation Routes

Cloudflare Page's function-invocation-routes config can be used to include, or exclude, certain paths to be used by the worker functions. Having a _routes.json file gives developers more granular control over when your Function is invoked. This is useful to determine if a page response should be Server-Side Rendered (SSR) or if the response should use a static-site generated (SSG) index.html file.

By default, the Cloudflare pages adaptor does not include a public/_routes.json config, but rather it is auto-generated from the build by the Cloudflare adaptor. An example of an auto-generate dist/_routes.json would be:

{
  "include": [
    "/*"
  ],
  "exclude": [
    "/_headers",
    "/_redirects",
    "/build/*",
    "/favicon.ico",
    "/manifest.json",
    "/service-worker.js",
    "/about"
  ],
  "version": 1
}

In the above example, it's saying all pages should be SSR'd. However, the root static files such as /favicon.ico and any static assets in /build/* should be excluded from the Functions, and instead treated as a static file.

In most cases the generated dist/_routes.json file is ideal. However, if you need more granular control over each path, you can instead provide you're own public/_routes.json file. When the project provides its own public/_routes.json file, then the Cloudflare adaptor will not auto-generate the routes config and instead use the committed one within the public directory.