A front-end for 38k+ recipes for TOH, built with Astro.
This is an Astro project, check the documentation to get a general idea, and keep reading for the specifics.
This project implements a new Recipe Template to build TOH Recipe Pages.
The Recipe data data comes from tasteofhome.com/wp-json REST API (see src/lib/recipe.ts
).
The Template lives src/templates/Recipe.astro
.
To see the new Pages, use /recipe/%slug%/
: defined src/pages/recipes
, this URL structure is actually divided in two different routes (for performance and cost-saving reasons, see Building and hosting!):
[static].astro
will serve URLs listed in getStaticPaths
, pre-rendering them at build time.[slug].astro
won't pre-render, and will call WP APIs at view time.The following tests are implemented:
Run all tests locally and make sure they pass before using CI/CD minutes!
For technical details, see package.json
(and Commands below), GitLab/GitHub pipelines, and recommended extensions for VSCode Workspace.
Astro will build complete pages using the data from the API and the templates in this repository. If you want to see those built pages, you need to host them somewhere.
This project is configured for hybrid
rendering. At build time, static routes will be generated as static HTML files, and dynamic routes will need a server.
Statically generated pages can be hosted pretty much anywhere, you can even see them locally in most cases. Server-Side Rendered pages need a server running, also generated by Astro using Adapters. The Adapter depends on the hosting platform (see "Deploy" step in pipeines). Different hosting platforms need different type of server code (and different Adapters for Astro to generate the right thing), and different settings.
Right now this project is set up for Cloudflare Pages.
To keep using Cloudflare Pages as is, add the necessary secrets to the CI/CD pipeline: CLOUDFLARE_ACCOUNT_ID
and CLOUDFLARE_API_TOKEN
, and the CLOUDFLARE_PROJECT_NAME
variable (this one is public), are required by Wranger to deploy.
Note that with Cloudflare Pages (and similar hosting providers), there are different considerations to decide between SSG (static) and SSR (server): SSG will add to build time and there's a limit of 20k files, but bandwidth will be free; SSR build time doesn't change with the number of pages, but each request hitting the server comes at a cost ($). If we could fit all the pages in SSG model, building the site would take longer but serving it would be free. If we had to keep everything SSR, build would be super fast but serving our traffic may become expensive.
All commands are run from the root of the project, from a terminal:
Command | Action |
---|---|
npm install | Installs dependencies |
npm run dev | Starts local dev server at localhost:4321. 🚀 |
npm run build | Build your production site to ./dist/ |
npm run preview | Preview your build locally, before deploying |
npm run astro ... | Run CLI commands like astro add , astro check |
npm run astro -- --help | Get help using the Astro CLI |
npm run lint | Run ESLint to check code quality |
npm run e2e-test | Run end-to-end tests using Playwright |
npm run unit-test | Run unit tests with Vitest |
npm run test | Run both unit and end-to-end tests |
npm run pr-check | Check code formatting with Prettier |
npm run pr-fix | Fix code formatting issues with Prettier |
npm run check | Run linting and code formatting checks |
npm run local-perf | Collect local performance data with Lighthouse |