This Is NOT a Component, IT'S a View, IT'S NOT Modular: Laravel Inertia vs Livewire

What we have is NOT a component in Laravel Inertia. At least, it's not a component per se in the context of our application.

What the hell am I talking about, you might ask?

I'll give you a little context here. Obviously, this is—so to speak—a personal interpretation, once one has developed applications using Laravel Inertia, which is precisely what we're looking at.

Laravel, among other technologies, is associated in some way with certain concepts, and one of them is that of a component. But, again, this is mostly a personal interpretation. I'll tell you why I consider this not a component, but simply a view:

        <contact-layout>
           <general-form :errors="errors" :contactGeneral="contactGeneral"/>
           <company-form :contactCompany="contactGeneral.company"/>
        </contact-layout>

But… how is it not a component?

The first thing you could tell me is:

“Look, that’s obviously a component! It’s a damn component in Vue! Aren’t you seeing it, for God’s sake?”

And yes… the code above is a .vue file. We have a component we're importing, called Contact. It obviously has its own <template> and <script>. So, you can rightly say:

“That’s a component in Vue.”

And yes, that's correct.

But...
To understand my point of view a little bit (which, as I said, I'll compare later), it's important to see how sister technologies like Livewire and Inertia behave. And as odious as comparisons are, they must be made.

What do I mean by this? What we're using in Inertia is, in fact, a view.

Let's remember that one of the main features we have in Laravel Inertia is the use of Vue, or rather, the ability to use Vue. Because we can even return a Blade view instead of a Vue view. It's that simple.

From the ground up: components in Laravel

To make my point even clearer, let's get back to basics. In Laravel, components were typically used to define, for example, buttons. That is, simple elements that didn't require additional logic.

We could have something like:

1. Anonymous components, more organized than a single view.
2. Classy components, which did require some logical initialization.

So, with those concepts clear, I ask you:

What do you think we have in the code above?

Because if you look closely, in Inertia we're forced to manually pass the data for the component to work. This is because, as they are independent technologies, there's no deep integration, and there probably never will be.

Comparison with Livewire

In the Livewire example:

@livewire('contact.company', ['parentId' => $pk])

We simply pass it an identifier to build the component. Using that ID, the related class is internally searched for:

    function mount($parentId)
    {
        $this->parentId($parentId);
    }


    function parentId($parentId)
    {
        $this->parentId = $parentId;
        $c = ContactCompany::where('contact_general_id', $this->parentId)->first();
        if ($c != null) {
            $this->name = $c->name;
            $this->identification = $c->identification;
            $this->extra = $c->extra;
            $this->choices = $c->choices;
            $this->email = $c->email;
        }
    }


    public function render()
    {
        return view('livewire.contact.company');
    }

—which in this example could be ContactCompany—. Livewire automatically executes the mount method, initializes the component, and you don't have to worry about manually passing it all the data.

Whereas in the case of Inertia, in addition to the ID, you have to pass it the class instance, which is usually constructed in the edit method.

Conclusion

So, in our Inertia component (that .vue file we showed earlier), we're simply importing a view and passing it data to initialize it manually. There's no Vue component instance as such with a server-controlled lifecycle.

That's why I don't consider it a component as such, but simply a rendered view with data.