Routage

bext utilise un routeur hautes performances basé sur trie pour la correspondance d'itinéraire O (profondeur). Les itinéraires sont découverts automatiquement à partir de la structure de fichiers de votre projet et peuvent être complétés par des réécritures, des redirections et des règles de rendu par itinéraire dans bext.config.toml.

Routage basé sur des fichiers#

Placez les fichiers de page dans le répertoire de votre application (par défaut : src/app/ ) et bext mappe la structure du répertoire aux chemins d'URL. Le scanner reconnaît page.tsx, page.ts, page.jsx et page.js comme composants de page.

src/app/
  page.tsx             ->  /
  about/page.tsx       ->  /about
  blog/page.tsx        ->  /blog
  blog/[slug]/page.tsx ->  /blog/:slug
  contact/page.tsx     ->  /contact

Les fichiers de mise en page ( layout.tsx ) sont automatiquement détectés et imbriqués. Les limites d'erreur ( error.tsx ), les états de chargement ( loading.tsx ) et les pages introuvables ( not-found.tsx ) sont colocalisées avec leurs itinéraires et récupérées par le scanner.

Vous pouvez changer le répertoire de l'application avec server.app_dir :

[server]
app_dir = "src/pages"

Itinéraires dynamiques#

Utilisez la syntaxe entre crochets pour les segments de chemin dynamique. La valeur du paramètre est disponible pour votre composant de page au moment du rendu.

Les segments dynamiques sont capturés en tant que paramètres nommés. Plusieurs segments dynamiques dans un seul itinéraire sont entièrement pris en charge.

Itinéraires fourre-tout#

Utilisez la syntaxe de propagation [...slug] pour faire correspondre n'importe quel nombre de segments de chemin :

src/app/
  docs/[...slug]/page.tsx  ->  /docs/*slug

Cela correspond à /docs/getting-started, /docs/guides/routing, /docs/a/b/c, etc. Le paramètre slug reçoit le chemin restant complet sous forme de chaîne (par exemple, "guides/routing" ).

Itinéraires API#

Les fichiers nommés route.ts, route.js ou route.tsx sont traités comme des gestionnaires de routage API plutôt que comme des pages. Exportez les fonctions nommées pour chaque méthode HTTP :

src/app/
  api/users/route.ts       ->  /api/users (GET, POST)
  api/users/[id]/route.ts  ->  /api/users/:id (GET, PUT, DELETE)

Le scanner inspecte les exportations et enregistre uniquement les méthodes fournies par votre fichier ( GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS ).

Réécritures et redirections#

Configurez les réécritures et les redirections d'URL dans bext.config.toml sans toucher au code de l'application. Ceux-ci sont traités avant la consultation du itinéraire.

# Rewrites (internal, URL stays the same in the browser)
[[route_rules]]
pattern = "/old-blog/*"
proxy = "blog-upstream"

# Redirects (301 by default)
[[route_rules]]
pattern = "/legacy/*"
headers = { "location" = "/new/$1" }

# Per-route rendering overrides
[[route_rules]]
pattern = "/blog/*"
render = "isr"
ttl_ms = 3600000
swr_ms = 600000

[[route_rules]]
pattern = "/dashboard/*"
render = "ssr"
cache = false

[[route_rules]]
pattern = "/marketing/*"
render = "static"

Le champ render accepte quatre modes :

Priorité d'itinéraire#

Lorsque plusieurs modèles peuvent correspondre à une demande, bext résout l'ambiguïté avec un ordre de priorité fixe :

1. Chemins statiques exacts -- /about bat /[slug]
2. Préfixes plus longs -- /blog/posts bat /blog
3. Segments statiques sur dynamique -- /blog/featured bat /blog/[slug]
4. Segments dynamiques sur fourre-tout -- /docs/[section] bat /docs/[...slug]
5. Ordre de définition antérieur -- lorsque deux modèles sont structurellement identiques, celui défini en premier dans l'arborescence de fichiers l'emporte

Les règles de routage définies dans bext.config.toml suivent l'ordre des gains de préfixe le plus long. Une règle avec le modèle /products/:id remplace une règle /products/* plus générale pour les chemins tels que /products/42.

Routage local i18n#

Lorsque i18n est configuré, le routeur extrait un préfixe de paramètres régionaux de l'URL avant de faire correspondre :

[i18n]
locales = ["en", "fr", "de", "es"]
default_locale = "en"
strategy = "prefix"

Avec la stratégie de préfixe, /fr/about se résout en paramètres régionaux "fr" et route /about. Les demandes sans préfixe de paramètres régionaux sont redirigées vers /{default_locale}{path}. Les paramètres régionaux sont inclus dans les clés de cache ISR afin que chaque version linguistique soit mise en cache indépendamment et que l'en-tête Content-Language soit défini automatiquement.

En-têtes personnalisés par itinéraire#

Les règles de routage peuvent injecter des en-têtes de réponse sur les chemins correspondant :

[[route_rules]]
pattern = "/api/*"
headers = { "cache-control" = "no-store", "x-robots-tag" = "noindex" }

[[route_rules]]
pattern = "/assets/*"
headers = { "cache-control" = "public, max-age=31536000, immutable" }

Ceci est utile pour définir des en-têtes de sécurité, des politiques de cache ou des remplacements CORS sur des groupes de routes spécifiques sans modifier le code de l'application.

En rapport#

• Pipeline de rendu PRISM — comment les routes basées sur des fichiers se compilent en bundles V8
• Mise en cache — Paramètres ISR, TTL et SWR par itinéraire qui complètent les règles d'itinéraire
• Frameworks : routage — conventions de routage spécifiques au framework (routeur d'application Next.js, Hono, etc.)
• i18n — routage des préfixes régionaux, Content-Language et clés de cache par paramètres régionaux
• Configuration : bext.config.toml — référence complète [[route_rules]]