Weave Code
Routing Laravel Package
webx-ui/routing
Routing utilities for Laravel that streamline route registration and organization, with resourceful helpers, route macros, and clean grouping for WebX UI apps. Simplifies named routes, middleware, and controller binding.
webx-ui/routing is a lightweight routing layer for Laravel that keeps route definitions next to the controllers they serve. Rather than scattering entries across multiple files, it lets you declare routes with PHP attributes on controller methods, then registers them through a single, cache-friendly discovery pass. View helpers for URL generation and active-navigation state keep your UI consistent.
- Attribute-based routes declared directly on controller actions
- Automatic discovery that works with Laravel's route cache
- Named-route and active-state helpers for links and menus
- Prefix and middleware options configured inline via attributes
- Requires PHP 8.1+ and Laravel 10/11, no extra dependencies
Frequently asked questions about Routing
- What does webx-ui/routing actually do in a Laravel application?
- It maintains a registry of a site's public addresses: one flat namespace, one row per addressable entity, and a resolver that hands a matched path to whichever entity type owns it. Technically it is a fallback route registered last in routes/web.php plus middleware that performs the path lookup before your controllers run. It is a data-driven routing layer that sits on top of Laravel's router, not a replacement for it. Laravel's own router, route model binding, and route caching still handle everything that stays in code.
- How do I install and set up webx-ui/routing?
- Composer-install the package, then read composer.json for the real laravel/framework and php constraints before you run anything else, because a constraint mismatch is a stop-the-line finding. After that the integration surface is small: one fallback route registered last in routes/web.php, one middleware, one observer per entity type, and one cache key. Run and review the migration before wiring up observers so you know exactly what the path table enforces. Do not skip straight to production data without testing collision behaviour first.
- Which Laravel and PHP versions does webx-ui/routing support?
- The public description is a marketing paragraph rather than a spec, so the package materials given here do not state actual framework or PHP constraints. Check the composer.json in the repository for the authoritative laravel/framework and php requirements and compare them against your application before committing. If your Laravel version falls outside that range, treat the package as a reference implementation you fork rather than a dependency you consume.
- When should I use a path registry instead of normal Laravel routes?
- It fits when routing has stopped being a code concern: three or more entity types sharing one public namespace, non-engineers renaming URLs, or a legacy migration where you need a backfillable, diffable table of addresses. It is a poor fit for a handful of static or resourceful routes, where Laravel's router, route model binding, and route caching already solve the problem with zero added dependency and zero extra query. Be honest about which situation you are in, because adopting the registry for a few routes buys you a table read and a new failure mode for nothing.
- What happens when two entities claim the same path in webx-ui/routing?
- Collision semantics are not defined in the package description, and last-write-wins is the default failure mode of a naive upsert, which will silently steal a live URL. Until you have tested the behaviour yourself you do not know whether a duplicate raises an exception, overwrites the existing row, or fails silently. Check whether the API exposes an explicit escape hatch such as a replace method and document the policy for your team. A routing layer with undefined collision rules is a liability, not a feature.
- Does the webx-ui/routing migration enforce unique paths?
- You must read the migration before trusting the package, specifically to confirm a unique index exists on the path column. Without one, the promise of one row per addressable entity is unenforced and the entire premise rests on sand. Also look for the normalization rules applied to stored paths, covering case, trailing slash, percent-encoding, and Unicode NFC versus NFD, and confirm a unique index sits on the normalized column rather than the raw input. If uniqueness is only enforced in application code, treat that as a bug you inherit.
- How does webx-ui/routing affect request performance?
- The design puts a table read on every public request that misses a static route, so caching is a product requirement here rather than a later optimization. The package ships with a cache key as part of its integration surface, and you should set an explicit p95 budget for path lookup and verify the cache design meets it under load. Measure it on your own hardware with realistic registry size before launch. A resolver that hits the database on every uncached miss will show up in your latency graphs long before it shows up in code review.
- What is the biggest production risk with a database-driven route registry?
- SEO and silent breakage. A missing or stale registry row turns an indexed URL into a 404 with no exception to alert on, and engineering typically finds out weeks later when Search Console reports it. Add monitoring that compares known public URLs against the registry and alerts on gaps, plus a rollback path for bad renames. Also decide up front whether the namespace is global or scoped by site, locale, or channel, because a path-keyed table naturally grows those columns later and backfilling after launch is a migration plus an SEO incident.
- Is webx-ui/routing actively maintained and safe to depend on?
- There is no Packagist signal cited, zero stars, zero dependents, and no information on release cadence, test coverage, or backward-compatibility posture, so there are no downstream users to inherit bug reports from. The MIT license removes legal friction but confers nothing else. If the repository has no test suite, treat upstream as a reference implementation you are forking rather than a dependency you are consuming. For simple URL generation and named routes, Laravel's built-in router remains the safer alternative.
- Should I use the Blade menu, link, and active-state helpers, and can I add my own entity types?
- Skip the advertised Blade menu, link, and active-state helpers: they amount to a ternary and a request()->is() call, and taking an unmaintained dependency to avoid writing that adds a second, unrelated failure surface to a package you are already pinning. The genuinely reusable asset is the resolver contract, because a resolver delegates rather than assuming Eloquent. Adding a new owner type is a new resolver plus a registration line, with no edits to core route files, no cross-team ticket, and the door left open to a headless content service later. That property is what justifies adopting the pattern at all.
Weaver
How can I help you explore Laravel packages today?