Replies: 1 comment
-
|
You're right that the Here's a working approach: // fresh.config.ts
import { defineConfig } from "$fresh/server.ts";
import { walkSync } from "jsr:@std/fs/walk";
import { relative } from "jsr:@std/path";
function discoverIslands(dirs: string[]): string[] {
const islands: string[] = [];
for (const dir of dirs) {
try {
for (const entry of walkSync(dir, {
exts: [".tsx", ".ts", ".jsx"],
includeDirs: false,
})) {
islands.push(`./${relative(".", entry.path)}`);
}
} catch {
// Directory doesn't exist yet, skip
}
}
return islands;
}
const featureIslands = discoverIslands([
"./features/users/islands",
"./features/products/islands",
"./features/checkout/islands",
]);
export default defineConfig({
server: {
islandSpecifiers: featureIslands,
},
});Or if you want a convention-based glob (any import { walkSync } from "jsr:@std/fs/walk";
function discoverFeatureIslands(): string[] {
const islands: string[] = [];
for (const entry of walkSync("./features", {
exts: [".tsx", ".ts", ".jsx"],
includeDirs: false,
})) {
// Only include files under an "islands" directory
if (entry.path.includes("/islands/")) {
islands.push(`./${entry.path}`);
}
}
return islands;
}This pattern works well with the feature-based directory structure you described. The key insight is that One thing to note: Fresh's dev server won't automatically pick up new island files added after startup (since the specifiers are computed at config time). You'd need to restart the dev server when adding a new island file to a feature directory. That's the same limitation the standard |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi all,
I noticed in "The road to Fresh 2.0" (#2363), there was a hypothetical
app.addIsland(...)method proposed briefly which I found interesting.Currently it seems you can manually declare islands with the Vite config using the
islandSpecifiersarray, but it doesn't look like there's anywhere to declare a glob of "island" directories, which might be useful for more advanced use cases e.g. adopting "organised-by-features-not-concern" directory structure.E.g. let's say I have:
/features /users /components <- fullstack /handlers <- server /islands <- client /pages <- fullstack /services <- server(let's assume I'm not using file based routing at this stage and I'm wiring up routes manually)
It'd be cool to be able to have any components in
/features/users/islandswork like any normal island.Maybe this conceptually clashes too much with the framework though; I've just found this sort of structure nice in a FastAPI (Python) project and now I'm trying to imagine my ideal counterpart in the JavaScript world, where we have the benefit of using the same language on the fronted and backend, which is especially convenient for SSR purposes...
Beta Was this translation helpful? Give feedback.
All reactions