ReviewOS

also looking at this

reviewos/reviewos.org

fix(views): tell route.serve where the components live

#5
Merged glennmichael123 wants to merge fix/stx-components-route-serve into main
2 files +28 -0
routes/views.tsadded+25-0
Changes to routes/views.ts
@@ -0,0 +1,25 @@
1import { route } from '@stacksjs/router'
2import ui from '../config/ui'
3
4/**
5 * Not a route: where the file-based views find their components.
6 *
7 * Two servers render stx here and only one of them was told. The dev frontend
8 * goes through bun-plugin-stx, which loads `config/ui.ts` itself and searches
9 * `resources/components`. Everything that boots through `route.serve()` - the
10 * API server behind `./buddy dev`, the e2e suite, a production boot - renders
11 * through bun-router's file-based routing instead, which never reads that
12 * config: it falls back to `<viewsDir>/components`, a directory this project
13 * does not have, and every `<Component />` tag on those boots renders as an
14 * "[Error loading component]" line in the page. `<CsrfField />` is one of
15 * them, so any form served that way loses its token and submits into a 403.
16 *
17 * This file runs with the other route files, which both boot paths import
18 * before serving, so the render config is set wherever rendering happens.
19 *
20 * `componentsDir` only, deliberately. `config/ui.ts` also names a layoutsDir
21 * of `resources/layouts`, which does not exist - layouts live under
22 * `resources/views/layouts`, exactly where bun-router's fallback looks, so
23 * forwarding the config value would break every page while fixing nothing.
24 */
25route.bunRouter.views({ componentsDir: ui.componentsDir })