How to Pass Parameters Correctly in Inertia.js: Avoiding Query String Confusion

As developers building modern, full-stack applications with Inertia.js and Laravel, managing routing and data passing is crucial. It’s a common point of confusion when transitioning from traditional server-side rendering patterns to the seamless SPA experience provided by Inertia.

I understand the exact issue you are facing: you have defined a route with a parameter (/blogs/{post}), and while manual navigation works, using Inertia's <Link> component results in a query string (/blogs/?post=1) instead of the desired clean route segment (/blogs/1). This happens because the way Inertia constructs links needs to be explicitly told how to handle route parameters versus simple query strings.

This post will dive deep into why this happens and provide the correct, idiomatic way to pass parameters in your Inertia links, ensuring your application adheres to clean RESTful routing principles, much like when structuring controllers within Laravel.

---

Understanding the Difference: Route Parameters vs. Query Strings

The confusion stems from the fundamental difference between two ways of passing data in a URL:

1. Route Parameters (Segments): These are variables defined directly in your route definition (e.g., /blogs/{post}). They are intended to identify a specific resource and should be part of the path itself.
2. Query Strings: These are appended after a question mark (?) and are used for filtering, sorting, or optional data (e.g., /blogs?sort=new).

When Inertia builds links using simple string concatenation or default link methods, it sometimes defaults to appending parameters as query strings if it doesn't recognize the context of a named route parameter correctly.

The Solution: Using Laravel's route() Helper

The most robust and recommended way to generate dynamic links within an Inertia application is by leveraging Laravel’s powerful route() helper function. This ensures that you are generating URLs based on defined route names, not manually stitching strings together.

In your Vue component, instead of constructing the path manually, you should instruct Inertia to use the named route provided by Laravel.

Correct Implementation Example

Let's look at how you can modify your Vue component to correctly generate the link using the route() function:

<div class="wrapper" v-if="blogs.length">
  <div class="blog" v-for="blog in blogs" :key="blog">
    <!-- CORRECT WAY TO GENERATE THE LINK -->
    <Link :href="route('blogs.show', blog.id)">
      <small>posted by: {{ blog.id }}</small>
      {{ blog.title }}
    </Link>

    <button type="button" @click="destroy($event, blog.id)">
      Delete post
    </button>
  </div>
</div>

Explanation of the Fix

1. Route Definition: Ensure your route remains clean: Route::get('/blogs/{post}', [BlogController::class, 'show'])->name('blogs.show'); (Note the use of ->name()).
2. Inertia Link: By using :href="route('blogs.show', blog.id)", you are telling Inertia to look up the defined route named blogs.show and substitute the dynamic segment {post} with the actual value from blog.id.

This approach ensures that the resulting URL is cleanly structured as /blogs/1, which aligns perfectly with RESTful routing principles, similar to how you structure resource relationships when working with Eloquent models in Laravel. This practice keeps your application highly maintainable and predictable, regardless of whether you are using Inertia or raw Laravel controllers.

Best Practices for Data Passing in Inertia

When passing data between the backend (Laravel) and the frontend (Vue/React via Inertia), follow these guidelines:

1. Use Route Names: Always define named routes in your web.php file (e.g., using ->name()). This decouples your frontend from the physical URL structure, making refactoring easier.
2. Route Parameters for IDs: Use route parameters (/resource/{id}) for identifying specific resources, as demonstrated above.
3. Use Query Strings for Filtering: Reserve query strings (?key=value) strictly for filtering, pagination, or optional search parameters. Never use them to pass primary resource identifiers if a dedicated route segment exists.

By adopting the route() helper within your Inertia links, you move away from manually managing URL strings and embrace Laravel's routing system, resulting in cleaner, more reliable navigation experiences.

---

Conclusion

Dealing with routing nuances is an inevitable part of full-stack development. The issue you encountered—query strings appearing instead of clean route segments—is a classic symptom of mismanaging how dynamic parameters are injected into Inertia links. By consistently utilizing Laravel's route() helper, you ensure that your frontend interactions are tightly integrated with your backend routing structure. This practice not only solves your immediate problem but also reinforces the architectural consistency expected when building applications on the robust foundation provided by frameworks like Laravel and Inertia.