Livewire Version 3

[Tinisha]

Mostof the major third-party Livewire packages either currently support Livewire 3 or are working on supporting it soon. However, there will inevitably be packages that take longer to release support for Livewire 3.

Livewire's default class_namespace has changed from App\Http\Livewire to App\Livewire. You are welcome to keep the old namespace configuration value; however, if you choose to update your configuration to the new namespace, you will have to move your Livewire components to app/Livewire:

In this case, we've found a string configuration to be too rigid. Therefore, Livewire 3 has chosen to use runtime configuration instead. You can reference our documentation on configuring Livewire's update endpoint for more information.

To import Livewire into your bundle, you must first disable Livewire's normal JavaScript injection and provide the necessary configuration to Livewire by replacing @livewireScripts with @livewireScriptConfig in your application's primary layout:

Because Livewire now supports multiple paginators per component, it has removed the $page property from the component class and replaced it with a $paginators property that stores an array of paginators:

Livewire's prefetching feature (wire:click.prefetch) has been removed entirely. If you depended on this feature, your application will still work, it will just be slightly less performant in the instances where you were previously benefiting from .prefetch.

In version 2, Livewire exposed a dedicated JavaScript method for customizing the page expiration behavior: Livewire.onPageExpired(). This method has been removed in favor of using the more powerful request hooks directly:

Last Wednesday at Laracon Online, Caleb Porzio gave a talk called "The Future of Livewire" demoing all the new features planned for Livewire v3. In this article, we'll go over those features again in case you missed the talk or want a second look.

The entire Livewire core has been rewritten. The new core relies on Alpine more, using its Morph, History, and other plugins under the hood, which means Livewire has better diffing, features can be built faster, and there's less duplication between Livewire and Alpine. Restructuring the codebase and relying on Alpine more also enabled several of the new features to be added.

After composer installing Livewire v2, you have to manually add @livewireStyles, @livewireScripts, and Alpine to your layout. With Livewire v3, you'll just install Livewire and everything you need is automatically injected - including Alpine!

Alpine has had transitions for a while, but Livewire v3 will have a wrapper around x-transition called wire:transition. Add wire:transition to any element that will be shown or hidden using Livewire and get those really nice transitions. Since wire:transition utilizes x-transition under the hood, all the modifiers like .opacity and .duration will be supported as well.

Livewire v3 will support writing JavaScript functions directly in your backend Livewire components. Add a function to your component, add a /** @js */ comment above the function, then return some JavaScript code using PHP's HEREDOC syntax and call it from your frontend. The JavaScript code will be executed without sending any requests to your backend.

Livewire v3 will support locked properties - properties that cannot be updated from the frontend. Add a /** @locked / comment above a property on your component, and Livewire will throw an exception if someone attempts to update that property from the frontend.

When Livewire was first released, it was primarily meant for writing components like search that needed a really "live" feel, so automatically sending updates to the server every time an input was updated made sense. Now, we're using Livewire to build all kinds of apps. As Livewire and its usage have evolved, we've realized that the "deferred" behavior makes more sense for 95% of forms, so in v3 "deferred" functionality will be the default. This will save on unnecessary requests going to your server and improve performance.

In Livewire v2, if you have multiple components using wire:poll or dispatching and listening for events, each one of those components will send separate requests to the server on each poll or event. In Livewire v3, there is intelligent batching of requests so that wire:polls, events, listeners, and method calls can be batched into one request when possible, saving even more requests and improving performance.

When using nested components in Livewire v2, if a property on the parent component is updated, the child component's data is not automatically kept in sync. There are manual workarounds using events and listeners, but it's not ideal. In Livewire v3, when you pass a piece of data to a child component, add a /** @prop */ comment above the property in the child, then update it in the parent component, it will be updated in the child component.

Another pain point in Livewire v2 is "modelling" a property from a parent to a child component. Say you wanted a component. It's not easy to pass in a value then have it automatically updated in the parent anytime it's updated in the child. In Livewire v3, you can add wire:model when using the input component, then inside the input component add a /** @modelable */ comment above the property where you're storing the value for the component and Livewire will handle the rest.

Livewire v3 will also include a new @teleport Blade directive that will allow you to "teleport" a piece of markup and render it another part of the DOM. This can sometimes help avoid z-index issues with modals and slideouts.

Livewire v3 will introduce "lazy" components. If you have a component that takes a while to load due to some expensive query or is rendered in a slideout that isn't always opened, you might want to wait to load it until it's shown on the page. In Livewire v3, just add a lazy attribute when rendering a component and it won't be rendered initially. When it comes into the viewport, Livewire will fire off a request to render it. You'll also be able to add placeholder content by implementing the placeholder method on your component.

In Livewire v3, you'll be abe to add wire:navigate to any anchor tag, and when clicked, Livewire will fetch the page in the background, then swap the DOM out really quickly giving your app a more SPA-like feel. If you add the .prefetch modifier as well, Livewire will prefetch the link's contents as soon as the link is hovered, making it feel even faster!

Another really cool Blade directive Livewire v3 will include is @persist. Using @persist in combination with wire:navigate, will enable you to have parts of your apps that "persist" across page changes. A good example of this functionality is a podcast player that continues to play while you move around in the app.

We're really looking forward to all these new features in Livewire v3. If your business relies on Livewire and you want to support the development of v3 or want help supporting your Livewire apps, consider joining the official Support Program.

This is the documentation for v2 but the latest version isv3.You can switch versions in the menu on the left/at the top.Check your current version with the following command:

In the last months, I have been working more and more with Laravel Livewire. I love this way of developing and handling so much stuff on the PHP side of things. One of the projects is called Refactoring PHP, and it will be a platform where you can share code snippets. Other users can then add suggestions for refactored versions of this code. You can check out the project by looking at my past live streams.Long story short, I was using Livewire a lot lately and ran into a few scenarios bugged me while testing.

When you create Livewire components by test-driven development, you start writing tests for the component you wish you had. Livewire provides some nice testing helpers that we can make use of. A test for our component might look something like this:

In this test, we are making sure we can set the message property and call the submit method of our component class. Then we also check if the email was sent. Tests are working, and everything looks good. But then we open the browser, and the page is empty. We haven't added our component to a view or route yet. Of course, we could add it, and everything would work. Still, I wanted to test this behavior first. All of our efforts to test the component are worthless if the component is not used. So with the next test, we want to make sure it gets included in another view.

It was a pretty simple one: the component's view file was empty. Wait, what? We tested our component, and it was working with an empty view file? Correct. Livewire assertion helpers are great at setting properties in the class or calling methods, but those helpers don't interact with the actual view file.

First, they are checking strings that can easily change, like the name of a label or button. Second, this is not quite what we want to test. What is our goal again? We don't care about what strings or tags are being used. We care about the properties and methods of our component. We want to make sure they are connected.

First, the test name already clarifies what we want to test; the connection between the class and view of our component. The assertPropertyWired helper makes sure that the property with the name message is wired inside our view. And by wired, we mean an HTML tag with wire:model="message". Similar to this, the assertMethodWired checks if an HTML tag is connected to a component method through wire:click="send".

These rules also help while thinking about where to test what. In my test for the feedback page, I could also test some component's specific behavior. But I want to make a clear distinction here. All tests regarding a component should be placed inside a test only dedicated to that component. The only exception is checking if it is used; this will be part of our page test again.

3a8082e126