Getting Started

Install the package with Composer and verify the dependency constraint resolves to livewire/livewire:^2.0. If your application is still on Livewire 1, Composer will usually surface the conflict immediately; upgrade Livewire first rather than forcing the package.
Publish any package config, views, or assets using the tags documented in the README, then inspect the package service provider to see what is registered automatically.
Confirm your layout includes Livewire 2’s required directives (@livewireStyles and @livewireScripts) before rendering any package-provided component.
Look first at the package’s Livewire component classes and traits, then at its published config. Those two places usually reveal the intended integration surface.
First use case: add a single package component to an existing Blade view, bind one Eloquent model or primitive property, and verify the round trip in the browser. This validates installation, asset loading, and Livewire 2 compatibility in one step.

Implementation Patterns

Use the package’s traits or base component class on your own Livewire components when you need its behavior without duplicating logic. Keep public properties primitive or serializable; Livewire 2 hydrates components between requests.
Bind models in mount() and use wire:model for form fields. Keep validation rules in the component’s $rules and merge in any package-provided rules.
Prefer Livewire events ($emit, $listeners) for cross-component communication instead of calling components directly. This keeps nested components decoupled and testable.
For CRUD screens, combine the package component with Blade components for layout and buttons. Let Livewire own state and actions; let Blade own presentation.
Test components with Livewire::test() and assert on state, validation errors, emitted events, and rendered output. Add feature tests for routes that render the component.
When integrating with existing admin panels, wrap package components rather than rewriting the panel’s layout. This limits the blast radius when the package updates.
Use the package’s published views as extension points when markup needs to change. Override only the views you need and keep a note of which ones you have customized.

Livewire 2 is a major upgrade from Livewire 1. Review the Livewire 2 upgrade guide before updating this package; common breakages include lifecycle hook behavior, event listener syntax, wire:model modifiers, and component property serialization.
If the application still depends on Livewire 1, do not update this package in isolation. Upgrade Livewire, run the full test suite, and then update the package.
Clear cached config and views after publishing or changing package configuration: php artisan config:clear and php artisan view:clear.
Watch for nested component issues. Use stable wire:key values in loops and avoid deeply nested package components unless the README explicitly supports them.
Debugging is easier when you inspect the Livewire payload in the browser network tab and temporarily log component lifecycle hooks. Most “state disappeared” issues are serialization or hydration problems, not package bugs.
If the package publishes assets, re-publish them after upgrading. Stale JavaScript is a common source of confusing behavior after a Livewire major version bump.
Extension points usually include published config, publishable views, and container bindings in the service provider. Prefer binding an interface or subclassing a package class over editing vendor files.
Pin the package and Livewire versions in composer.json for production, and run the upgrade in a branch with component tests before merging.