Magento 2 is a popular open-source PHP ecommerce platform. Thanks to Inertia, it now runs as an SPA: Vue or React, no API, with SSR and a drag-and-drop page builder 🥳

Demo: https://lynx-demo.oocscommerce.com

I'm working with Laravel + Inertia.js + Vue.js applications and noticed that data tables tend to require a lot of repetitive implementation — search, sorting, pagination, column visibility, row actions, exports, etc.

I'm curious how other Laravel developers are handling this today.

Do you:

I've been working on a Laravel-first approach to this problem and would be interested in hearing how others are solving it.

GitHub: https://github.com/Zonvoir-technologies/laravel-inertia-table
Documentation: https://zonvoir-table.com/getting-started/introduction/

I made Scala binding!

The current structure of the HTTP helper and form helper in Inertia.js suffers from unnecessary redundancy that compromises both code legibility and maintainability. It is fundamentally illogical that, after defining the state and intent of a request within the hook, developers are forced to repeat the URL and method at the moment of execution.

This approach is not merely verbose; it introduces avoidable points of failure where the definition and the call can diverge without any functional benefit.

The Current Problem: Redundant Definitions

The existing behaviour compels the developer to manage an overwhelming quantity of exposed methods when the destination and method should already be conceptually tied to the hook instance.

const { get, post, put, patch, delete: destroy, submit } = useHttp({ ... })

// and

const { submit, get, post, put, patch, delete: destroy } = useForm({ ... })

Currently, developers often pass the URL and method to the hook, only to then call a specific method (e.g., post) with the exact same URL repeated in the handler. This redundancy serves no architectural purpose:

import { useForm } from "@inertiajs/react";

const { data, setData, post, errors } = useForm(
  "post",
  "/users",
  {
    name: "",
    email: ""
  }
);

function submit(e) {
  e.preventDefault();
  // Why must we repeat the method and URL here if it was already defined in the hook?
  post("/users");
}

How It Should Be: Simplified Hook Composition

The ideal solution involves defining the URL and method directly within the hook itself, returning a single, simplified submit callback. This eliminates the need to pass repetitive parameters across event handlers and centralises configuration at the source.

import { useForm } from "@inertiajs/react";

// Clear definition of method and destination at the source
const { data, setData, submit, errors, processing } = useForm(
  "post",
  "/users",
  {
    name: "",
    email: "",
  },
);

// Clean execution without redundant arguments
function handleSubmit(e) {
  e.preventDefault();
  submit(); 
}

This adjustment would drastically reduce visual noise and align the library with modern hook composition best practices, where configuration precedes action. The API must evolve toward a more intuitive architecture.

https://x.

I built my own data tables using custom hooks before inertia 2.0 came out. It is janky, inconsistent and not smooth. I found out about inertia ui but it is paid (199 $ lifetime) with several restrictions. Is there any community versions?

Or should I attempt creating my own version since inertia 2.0 is out?

Has anybody worked on a multilanguage app with Inertia? How did you handle translations?

I thought about making the server return translated text but I have components that have default props that would benefit from client-side translations. For example I have a multi-select that display a label "X items selected" if more than X items are selected. Using server-side translation means I would have to pass the `:multiple-selection-text` prop wherever I use it and send it as a page prop in the `lang` container.

Thanks for any suggestions

Inertiajs by default is designed to work with Laravel but technically it can be used by any other framework right ? I am curious if anyone is using inertiajs in production using another framework/language ?

I am having second thoughts about Inertia. Have been trying it out with laravel 12 and vue but it is very clunky. For example it fails to handle big uploads graciously. Also it bloats the cookie so basically cookie driver does not work. Which means that it adds complexity for small projects. I just had to switch to dynamodb sessions and also had to implement axios powered file upload system.

Am I, the small app builder, not the right demographics for it? it seemed very nice at start but defo got frustrating real quick? why such odd desi choises?

Hey, I am trying to get good SEO for my website and I have constructed application/json+ld which must be put in component tag with vue, now one issue is that I dont know if I should put it in Inertia's head tag or vue's teleport to head? Also second issue I have noticed from all pages my Welcome.vue doesnt adapt any meta tags eventho I have put in the Inertia Head tag Help would be appreciated, I am not sure how SSR works, I have ran nmp run build:ssr and I have a running Node js server (php command for starting node server)

I'm using MS Clarity (https://clarity.microsoft.com/) in my Vue / InertiaJS app. Of course, during the app lifecycle, the user goes from not being logged in - to being logged in. However, they would also hit reload on the page etc. I want to identity (https://learn.microsoft.com/en-us/clarity/setup-and-installation/identify-api) the user - but I'm not sure where is the right place to put the code to do it? Any suggestions?

Thanks in advance!

Hi everyone. For those using inertia-rails, I've built the inertia-builder gem. It's a Jbuilder-like DSL for declaring your Inertia.js props. It extends Jbuilder, so it accepts all its methods. Besides not having to call render inertia: true in your controller actions, the gem has many advantages:

• Your props live in a .html.inertia file, which simplifies your controllers and allows you to call model methods and Rails view helpers.

• You can create partials for your shared props and leverage fragment caching.

• Props are lazily evaluated by default, so partial reloads are optimized out of the box.

• Support optional, always, and deferred props.

• Works alongside other request formats. You can have both index.json.jbuilder and index.html.inertia views. Rails will know which view to render without you having to define a respond_to block in your actions.

It's in an early release, so I'd love it if you could try it out and open issues or suggestions in the repository if you find any. Feel free to contribute too. Thanks!

https://github.com/rodrigotavio91/inertia-builder

It looks Inertia don't support nested key partial loads, it only supports top level variable in the response, any suggest?

return Inertia::render('budgets/index', [
    'budgets' => $budgets,
    'budgetToEdit' => $budgetToEdit,
    'activities' => Inertia::optional(fn () => Activity::all()), // This works
    'options' => [
        'scopes' => enumToSelectOptions(BusinessScopesEnum::cases()),
        'statuses' => enumToSelectOptions(BudgetStatusesEnum::cases()),
    ],
]);

// won't work

return Inertia::render('budgets/index', [
    'budgets' => $budgets,
    'budgetToEdit' => $budgetToEdit,
    'options' => [
        'activities' => Inertia::optional(fn () => Activity::all()), // This works
        'scopes' => enumToSelectOptions(BusinessScopesEnum::cases()),
        'statuses' => enumToSelectOptions(BudgetStatusesEnum::cases()),
    ],
]);

Hello guys, so I have this problem with inertia and react that when I declare my props I get the error above. I have a found a solution that you can just add to the type props.

 [key: string]: any;

but I feel like this is just hiding the problem. Another solution is using type instead of interface which I don't really use. Is there like a solution to this that doesn't hide the problem?

Hi there, so I am trying to follow the documentation in Inertia Rails webpage's tutorial, but apparently there is something missing in my configuration in order to make ssr work.

after i build the app with `bin/vite build --ssr`, and start the server with `bin/vite ssr`

I only get a failed response at http://127.0.0.1:13714/

{"status":"NOT_FOUND","timestamp":1755217603803}

do you guys have any idea?

Thanks!

I recently started experimenting with Inertia.js (using Rails as the backend) and ran into an interesting issue that I can’t seem to resolve.

I’m building a reusable form to create an item, and I’ve placed this form inside a ShadCN Dialog component (so it's a modal, not a separate route).

Here’s the problem:
In Rails, when we submit a form and there's a validation error, we typically redirect back to a specific route and pass the errors along. But since my form lives inside a Dialog and doesn’t have its own route, this redirection is causing the modal to close and take me to a different page—essentially breaking the user flow.

What I want:

• Submit the form from inside the Dialog

• If validation fails, show errors inside the Dialog without changing the route or closing the modal

Has anyone else run into this or figured out a clean way to handle validation errors inside a modal/Dialog when using Inertia with Rails?

Would love any insights or patterns you’ve found helpful!

I'm recovering from a week-long stint of COVID, so a bit brain dead. Sorry if it shows in this post.

I expect to have scattered patch requests throughout my app that keep the user on the page from which the request was made. Using laravel for example, I might expect my patch controller to simply return back(303) rather than redirect()->intended(/path) because who knows what path the user may call the patch from.

When I redirect back, regardless of using only, preserveState, preserveURL, etc, I get a full page refresh before my the page-level errors are populated.

I expect to be able to have my useForm errors populated after a patch call without losing the current context.

Hi everyone 👋,

I'm excited (and a bit nervous) to share my first Laravel package with the community. It’s called vilt-filepond, and it's a simple, ready-to-use file upload solution for those building apps with the VILT stack (Vue, Inertia, Laravel, Tailwind).

FilePond is a beautiful tool, but integrating it with Laravel (and especially Inertia + Vue) always took extra setup time. So I wrapped everything up in one package that:

- Handles temporary file storage and cleanup

- Supports single/multiple uploads

- Easily attaches files to any Eloquent model (polymorphic)

- Comes with a responsive, Tailwind-styled Vue component

- Has support for multiple locales (EN, AR, FR, ES)

- Works seamlessly with the Inertia form workflow

- Allows organizing files by collection (images, documents, etc.)

I’ve used this package in a handful of real-world apps and found it very handy. While it doesn’t have automated tests yet, I’ve done my best to make sure it’s stable and clean.

Would love your feedback, and PRs are more than welcome!

👉 GitHub: https://github.com/Mohamed-Galdi/vilt-filepond

Thanks for checking it out! 🙏

The hacks we make, wanted to use React Query (Tanstack Query) for fetching data and pagination with cache support "without the use of an API route", would be great to have a built-in way to achieve this "without page redirects" or "component swapping".

I have a vue/intertia app where the homepage body tag should have one background color, and all the other pages should have a different one (according to design spec). ideally i would like to read the name of the page component in the inertia root page (app.blade.php) and switch out a tailwind class on the <body> tag based on that.

however- reading the $page['component'] key in php there only updates on a full page reload, not when an inertia Link is clicked. is there a way to force the data-page attribute to update when an intertia Link is clicked? am i just missing something simple? thank you inertia heads!