Qwik City App ⚡️
Project Structure
This project is using Qwik with QwikCity. QwikCity is just an extra set of tools on top of Qwik to make it easier to build a full site, including directory-based routing, layouts, and more.
Inside your project, you'll see the following directory structure:
├── public/
│ └── ...
└── src/
├── components/
│ └── ...
└── routes/
└── ...
-
src/routes
: Provides the directory based routing, which can include a hierarchy oflayout.tsx
layout files, and anindex.tsx
file 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 and deployment
Use the npm run qwik add
command to add additional integrations. Some examples of integrations include: Cloudflare, Netlify or Express server, and the Static Site Generator (SSG).
npm run qwik add # or `yarn qwik add`
Development
Development mode uses Vite's development server. During development, the dev
command will server-side render (SSR) the output.
npm start # or `yarn start`
Note: during dev mode, Vite may request a significant number of
.js
files. This does not represent a Qwik production build.
Preview
The preview command will create a production build of the client modules, a production build of src/entry.preview.tsx
, and run a local server. The preview server is only for convenience to locally preview a production build, and it should not be used as a production server.
npm run preview # or `yarn preview`
Production
The production build will generate client and server modules by running both client and server build commands. Additionally, the build command will use Typescript to run a type check on the source code.
npm run build # or `yarn build`
Builder.io + Qwik
An example of using Builder.io's drag-and-drop headless CMS with Qwik.
See src/routes[...index]/index.tsx for the integration code.
How to use
Create a free Builder.io account (only takes a couple minutes), and paste your public API key into .env
- BUILDER_PUBLIC_API_KEY=YOUR_API_KEY
+ BUILDER_PUBLIC_API_KEY=abc123
Then run the development server:
npm run dev
Now, go set your preview URL to http://localhost:5173/
- Go to https://builder.io/models
- Choose the
page
model - Set the preview URL to
http://localhost:5173/
and clicksave
in the top right
Now, let's create a page in Builder.io and see it live in Qwik!
- Go to https://builder.io/content
- Click
+ New
and choosePage
- Give it a name and click
Create
Now, try out the visual editor! You can find a custom Qwik components
in the Custom Components
section of the insert tab.
You may also limit visual editing to only your custom components with components-only mode.
Next Steps
See our full integration guides here
Also, when you push your integration to production, go back and update your preview URL to your production URL so now anyone on your team can visuall create content in your Qwik app!
Also, to integrate structured data, see this guide
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.