- How does Laravel Actions improve code organization compared to traditional controllers?
- Laravel Actions shifts focus from *where* logic runs (controllers, jobs, etc.) to *what* it does, encapsulating single tasks in reusable classes. This aligns with Clean Architecture and DDD, reducing duplication and making logic testable as standalone objects (e.g., `PublishANewArticle::run()`).
- Can I use Laravel Actions with Laravel 13? What about older versions?
- Yes, Laravel Actions supports Laravel 11–13 (as of v2.10.0). Laravel 10 requires v2.9.x. Check the [release notes](https://github.com/lorisleiva/laravel-actions/releases) for version-specific changes before upgrading.
- How do I migrate an existing controller to an action without breaking the app?
- Start by creating an action with `php artisan make:action` and implementing `asController()`. Gradually replace controller logic in the action’s `handle()` method, then update routes to point to the action’s `asController()` method. Use feature flags for high-risk modules.
- Will Laravel Actions work with Inertia.js or API resources?
- Yes, actions integrate seamlessly with Inertia.js (tested in v2.7.3) and API resources. For APIs, return resources directly from `asController()` (e.g., `return new ArticleResource($article)`). The package doesn’t interfere with Laravel’s resource system.
- How do I test an action that runs as a job or listener?
- Use the package’s test helpers like `assertActionRuns()` or manually trigger actions via `app()->make(PublishANewArticle::class)->run()`. For jobs, mock the queue or use `Bus::fake()`. Listeners can be tested by dispatching events and asserting the action’s side effects.
- Does Laravel Actions add performance overhead?
- Minimal overhead—decorators add ~1–2ms per action. Job/listener actions may introduce slight serialization costs, but benchmarks show negligible impact for most use cases. Profile critical paths with Laravel Debugbar or Blackfire if needed.
- How do I handle middleware (e.g., auth, throttle) when using actions as controllers?
- Apply middleware to routes as usual (e.g., `Route::middleware(['auth'])->controller(PublishANewArticle::class)`). The `asController()` decorator respects Laravel’s middleware pipeline, including global middleware like `web` or `api`.
- Can I use Laravel Actions with Octane or serverless (Vapor) deployments?
- Yes, actions work with Octane via `asListener` for event-driven workflows. For Vapor, ensure actions are stateless or use shared storage for job/listener actions. The package doesn’t impose deployment restrictions beyond Laravel’s native support.
- What’s the best way to adopt Laravel Actions in a large legacy codebase?
- Pilot in a single module (e.g., ‘Orders’) to validate benefits. Use `make:action` for new features and incrementally refactor controllers. Leverage feature flags to isolate changes. Start with complex logic (e.g., multi-step workflows) for maximum ROI.
- Are there alternatives to Laravel Actions for decoupling business logic?
- Alternatives include Laravel’s native `Service` classes, packages like `spatie/laravel-commander`, or architectural patterns like CQRS. Laravel Actions stands out by unifying *all* entry points (HTTP, jobs, events) under a single, testable interface with zero boilerplate.