Seiten
Inhalt
@xpulse/router – Component Spec
Status: CONCEPT · Erstellt März 2026 Übergeordnet:
GLOBAL_concept-ecosystem.md,GLOBAL_concept-web.md
Übersicht
URL-Matching und Route-Verwaltung für das xPulse Ökosystem.
Eine Aufgabe: URL auf Handler matchen – nicht mehr.
Kennt keine Controller-Logik, kein Template, kein HTTP-Server direkt.
Nimmt Routes entgegen (von @xpulse/controller oder manuell) und
registriert sie bei @xpulse/http.
Dependencies
| @xpulse/router |
| ├── @xpulse/http ← registriert gematchte Handler beim Server |
| └── @xpulse/event ← router:registered feuern |
API
Initialisieren
| import router from '@xpulse/router'; |
| await router.init(); |
Registriert alle bekannten Routes bei @xpulse/http. Wird von @xpulse/app
nach @xpulse/controller aufgerufen – wenn alle Routes bekannt sind.
Route registrieren
| router.register('GET', '/', handler); |
| router.register('GET', '/info', handler); |
| router.register('GET', '/info/:page?', handler); |
| router.register('POST', '/contact', handler); |
Wird intern von @xpulse/controller aufgerufen – kann aber auch manuell
genutzt werden für Routen ohne Controller.
404 Handler
| router.notFound((req, res) => { |
| res.status(404).send('<h1>Seite nicht gefunden</h1>'); |
| }); |
Ohne expliziten notFound Handler gibt der Router eine schlichte
404 Not Found Plain-Text Response zurück.
URL-Pattern Matching
Unterstützte Pattern analog zu @xpulse/http:
| / ← exakter Match |
| /info ← exakter Match |
| /info/:page ← Pflicht-Parameter |
| /info/:page? ← optionaler Parameter |
| /tool/:tool/:page? ← mehrere Parameter, letzter optional |
| // Beispiel: /tool/chat/guide |
| router.register('GET', '/tool/:tool/:page?', handler); |
| // → req.params = { tool: 'chat', page: 'guide' } |
| // Beispiel: /tool/chat |
| // → req.params = { tool: 'chat', page: undefined } |
Gefeuerte Events
| Event | Payload | Wann |
|---|---|---|
router:registered |
{ method, path } |
wenn eine Route registriert wird |
router:matched |
{ method, path, params } |
wenn eine Route gematched wird |
router:not-found |
{ method, path } |
wenn keine Route matched |
| import event from '@xpulse/event'; |
| event.on('router:not-found', ({ method, path }) => { |
| // wird von @xpulse/logger automatisch geloggt |
| }); |
Zusammenspiel mit @xpulse/controller
@xpulse/controller ruft router.register() für jede gefundene
Controller-Methode auf – der Router muss Controller nicht kennen:
| @xpulse/controller → router.register('GET', '/info', InfoController@index) |
| @xpulse/controller → router.register('GET', '/info/bla', InfoController@bla) |
| @xpulse/router → http.route('GET', '/info', handler) |
| @xpulse/router → http.route('GET', '/info/bla', handler) |
Debug Integration
Wenn @xpulse/debug als devDependency installiert ist, stellt @xpulse/router
automatisch einen DataCollector bereit. @xpulse/debug discovert ihn via
node_modules/@xpulse/router/src/datacollectors/ – keine Konfiguration nötig.
| "optionalDependencies": { |
| "@xpulse/debug": "^1.0.0" |
| } |
Der RouterCollector (name: 'router', icon: '🔀') zeigt im Web Profiler:
- Matched Route (kv): Method, Path, Name, Params (als JSON wenn vorhanden)
- Registered Routes (table): alle via
router.register()bekannten Routen mit Method, Path, Name
Kein Toolbar-Badge (kein quantifizierbarer Wert pro Request).
Paket-Struktur
| @xpulse/router/ |
| src/ |
| index.js ← default export: router-Objekt |
| matcher.js ← URL-Pattern matching Logik |
| registry.js ← Route-Verwaltung (register, notFound) |
| test/ |
| matcher.test.js |
| registry.test.js |
| docs/ |
| index.md |
| api.md |
| _meta.json |
| Dockerfile |
| Makefile |
| README.md |
| package.json |
| xpulse.json |