- What is symfony/ux-live-component and what problem does it solve?
- symfony/ux-live-component is a Symfony UX package that turns Twig components into stateful, interactive UI components whose state and markup update over Ajax, without you writing custom JavaScript. It builds on symfony/ux-twig-component and is inspired by Laravel Livewire and Phoenix LiveView. You get server-side rendering, predictable state handling, actions, validation and form binding, plus smooth partial DOM updates via Stimulus controllers. For Laravel developers the mental model translates well, but the implementation is Twig plus Stimulus rather than Blade plus Alpine.
- Can I use symfony/ux-live-component in a Laravel application?
- No, not directly. The package is Symfony-first: it depends on Symfony 7.4+ and PHP 8.4+, and it assumes Symfony's HTTP kernel, Twig, the Stimulus bridge, Symfony's dependency injection container, event dispatcher, validator and serializer. Running it alongside Laravel would mean bootstrapping a second kernel, replacing Blade templates with Twig, and swapping Alpine/Inertia for Stimulus, which is untested territory with no Laravel documentation or dependents. For Laravel applications, Livewire is the equivalent, first-party choice.
- How does Symfony UX Live Component compare to Laravel Livewire?
- They share the same core idea: a PHP class holds component state, actions are called over Ajax, and the server re-renders a partial view that is patched into the DOM. The differences are ecosystem-level. Live Components use Twig templates, Symfony attributes like AsLiveComponent and LiveProp, and Stimulus for the frontend bridge, while Livewire uses Blade, PHP attributes and Alpine.js inside Laravel. If your team knows Livewire, the concepts carry over; the syntax, template engine and tooling do not.
- How do I install symfony/ux-live-component in a Symfony project?
- Install it with Composer in a Symfony application, for example composer require symfony/ux-live-component, and make sure symfony/ux-twig-component and the Stimulus bundle are present since Live Components build on them. You then register the bundle in bundles.php and let Symfony Flex add the default configuration. Frontend assets are typically served through AssetMapper or Webpack Encore with the Symfony Stimulus bridge. There is no supported installation path for a Laravel application.
- What PHP and Symfony versions does symfony/ux-live-component require?
- Current releases target Symfony 7.4 or newer and PHP 8.4 or newer, so older Symfony 5/6 and PHP 8.1-to-8.3 projects need an upgrade path first. Because it ships as part of the Symfony UX family, its version constraints generally track the supported Symfony release line. Check the package's composer.json for the exact constraint before planning an upgrade, since these minimums move with Symfony releases.
- How do LiveProp properties and component actions work?
- You mark a class as a live component with the AsLiveComponent attribute and expose state through LiveProp properties, which are serialized to the page and sent back on each request so the component stays stateful between interactions. Public methods annotated as live actions can then be triggered from the template, mutate those properties, and cause the server to re-render and patch only the affected markup. This keeps rendering server-side and deterministic while still feeling interactive to the user. Non-serializable or heavy state can be handled with custom hydration or by storing an identifier and reloading the entity.
- Does symfony/ux-live-component require Mercure for real-time updates?
- No. The core interactivity of Live Components runs over ordinary Ajax requests: an action fires, the server re-renders, and the partial is swapped in. Mercure, which sponsors the Symfony UX packages, is optional and is used when you want to push updates to clients from the server, such as live notifications or Turbo Streams. If your project already uses Laravel Echo with Pusher or Ably, that stack is not compatible out of the box and would need a bridge or replacement.
- How do form binding and validation work in a Live Component?
- Live Components integrate with Symfony's Form component, so you can bind a form to LiveProp properties, handle input changes as live actions, and let Symfony's validator surface field-level errors without a full page reload. The component re-renders with validation messages after each interaction, which gives Livewire-like behavior with Symfony's form and constraint system. Laravel's Form Requests and validation rules do not apply here; you would need to reimplement that logic with Symfony's validator and constraints.
- Can I use Doctrine entities or Eloquent models with LiveProp?
- LiveProp values must be serializable, so Doctrine entities are normally exposed by identifier and re-fetched from the entity manager on the next request rather than stored whole in the payload. You can also write custom hydrators and dehydrators for complex objects. Laravel's Eloquent is not supported by the package's defaults, and using it would require a custom serializer or normalizer layer plus a Laravel-to-Symfony persistence bridge. In practice, pairing this package with Eloquent is a significant integration project rather than a configuration change.
- How do I test Live Components, and where do I report issues?
- Live Components ship with testing helpers that let you render a component, call actions, assert rendered HTML and inspect property values inside Symfony's test framework, and you can add Panther or similar browser tests for JavaScript-driven behavior. Because the repository is a read-only sub-tree split of symfony/ux, bugs and pull requests belong in the main symfony/ux repository rather than here. Maintenance is tied to the Symfony UX release cycle and backed by Symfony sponsors, so version support follows Symfony's own support windows. Laravel projects cannot run these tests without a Symfony test kernel.