Nova Percentage Card Laravel Package

Getting Started

The 2.1.0 release adds a Get ResourceID capability — a first-class way to resolve the resource identifier for the current request/route/model without hand-rolling $request->route('id') or digging through route parameters. Start here:

1. Confirm the install — the package should already be in composer.json. If not:

   composer require <vendor>/<package>:^2.1
   

2. Check for publishable config (only if you need to override defaults):

   php artisan vendor:publish --provider="<Vendor>\<Package>\<Package>ServiceProvider"
   

3. Verify the version actually landed — release notes are terse, so prove the method exists before you build on it:

   composer show <vendor>/<package>
   php artisan about   # if the package registers a line here
   

4. First use case — the canonical one is resolving the resource being acted on inside a controller, form request, policy, or listener where you don't want to re-parse the route:

   use <Vendor>\<Package>\Facades\<Package>;
   
   public function show(Request $request)
   {
       $id = <Package>::resourceId();      // or the documented equivalent
       return Post::findOrFail($id);
   }
   

Look first at the package's facade/helper entry point and its service provider bindings — that tells you whether the ID is resolved from the route, the request, or a bound model. Then check whether the new release ships a config key (e.g. a route-parameter name) so you know what it assumes about your routes: the default is usually {id}, and an {post} binding will silently miss.

Implementation Patterns

Controller / Form Request resolution. The most common integration is letting the package own the "which resource?" question instead of repeating route-parameter names across the codebase:

class UpdatePostRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'title' => ['required', 'string'],
            // authorize against the resolved ID rather than a magic string
            'slug'  => [Rule::unique('posts', 'slug')
                ->ignore(<Package>::resourceId())],
        ];
    }
}

Policy and gate integration. Resource IDs are frequently needed before you have a model instance. Resolve the ID, then the model, then authorize — keep that order explicit so the 404-vs-403 distinction stays correct:

Gate::authorize('update', Post::findOrFail(<Package>::resourceId()));

Cross-checking against route model binding. If you already use implicit binding (Post $post), treat the package's ID as the raw identifier and the bound model as the hydrated one. Don't mix them in one method — pick one source of truth per action, otherwise you get two database round-trips and confusing behaviour when a route uses a non-ID binding key like {post:slug}.

Nested resources. For /posts/{post}/comments/{comment}, this is exactly where a generic resourceId() gets dangerous. Explicitly scope:

$commentId = <Package>::resourceId();          // which one? post or comment?
$post      = Post::findOrFail($request->route('post'));
$comment   = $post->comments()->findOrFail($commentId);

Always scope the resolved ID through its parent relationship rather than trusting it globally — that's a tenancy/authorization win, not just a style preference.

Queues and jobs. If the helper resolves from the current request, it will be empty or wrong inside a queued job. Pass the ID into the job constructor explicitly and resolve the model in handle(); don't call the helper from a job context.

Gotchas and Tips

• Release notes are one line. "Get ResourceID" doesn't document the method name, return type, or failure mode. Confirm whether it returns int|string|null, throws when nothing is resolvable, or returns null. Read the source or the test suite before wiring it into a policy — a silent null reaching findOrFail produces a 404 where you expected a 403.
• Not a Laravel core API. Don't confuse this with $request->route('id') or Model::getRouteKey(). It's package-specific; new team members will not recognise it. Keep usage concentrated in a small number of places, or wrap it in your own thin helper so swapping it out later is a one-file change.
• Route parameter naming is the usual failure point. If your routes use {post} instead of {id}, the resolver may miss. Check whether 2.1.0 exposes a config option for the parameter name; if not, standardise route parameter naming across the app.
• Livewire / Inertia / API contexts behave differently. In a Livewire component the "current request" may be the Livewire update endpoint, not the page route — resolve from $this->route(...) or pass the ID as a public property instead. In API routes, make sure the package isn't expecting a web-session-bound resource.
• Debugging tip. When the ID comes back wrong or null, dump the whole picture at once rather than guessing:

  dd($request->route()->parameters(), <Package>::resourceId());
  

  Nine times out of ten the route parameter key differs from what the package expects.
• Test the boundary, not the helper. Since the package is thin, unit-testing it adds little. Add feature tests that hit your actual routes and assert the correct model is resolved — that catches route-naming regressions the package will never warn you about.
• Upgrade check for 2.x. This is a minor release; confirm no signature change to any existing method you already call before bumping in a shared codebase. Run your existing feature suite after composer update rather than assuming a minor bump is inert.
• Extension points. If the resolver is bound in the container, you can rebind it in a service provider to support custom route keys or tenant-scoped resolution — preferable to wrapping the facade everywhere, and it survives future releases.