Finish the Astro site

Finish the notes site with one deliberate island: a topic filter.

Render the complete published-note list as HTML first. The page must remain readable and every note link must work before JavaScript runs. Then add a small framework component that enhances the list by hiding notes outside the selected topic.

Choose its client directive from the experience you want. Use client:load only if filtering is part of the page’s immediate purpose. If the filter sits below a useful introduction, client:idle may be enough. Write the reason next to your implementation notes; “this is what I always use” is not a reason.

Run the production build and verify:

1. the collection schema accepts every published entry
2. draft notes produce neither links nor detail pages
3. every dynamic route has a title, description, and one main heading
4. local images have generated dimensions and useful alt text
5. the page still exposes all content and links without JavaScript
6. only the filter’s framework code loads in the browser

Preview the build, then deploy it. On the real domain, test a nested note URL, the custom 404, an optimized image, and the filter under network throttling. Check response status codes and browser requests rather than relying on appearances.

Finally, record three facts: how many routes were generated, which routes are static or on demand, and why each client-side script exists. If you cannot explain a script, remove its directive and test whether the site improves.

You now have the mental model for larger Astro projects: data is loaded and validated at a defined boundary, routes decide when HTML is produced, components compose that HTML, and islands add browser execution only where the user experience requires it.