- How does laravel-data compare to Laravel’s built-in Form Requests and API Resources?
- Laravel-data unifies validation and serialization into a single typed object, reducing redundancy. Unlike Form Requests (validation-only) or API Resources (serialization-only), it handles both while adding TypeScript generation and lazy properties for partial transforms. It’s ideal for complex APIs where data contracts need strict consistency across layers.
- Can I incrementally adopt laravel-data without rewriting existing Form Requests or API Resources?
- Yes. Start by replacing new features or non-critical endpoints. The package is designed to coexist with existing Laravel components. For validation, migrate rules incrementally by defining them in data objects. Serialization can be adopted per resource, avoiding a full rewrite.
- Does laravel-data support custom validation logic beyond Laravel’s built-in rules?
- Absolutely. You can use custom validation logic via the `rules()` method or by extending the `Data` class. For complex cases, leverage Laravel’s validation rules or create custom rules within the data object’s constructor or methods. The package also supports custom casts for transforming data before validation.
- What’s the performance impact of using reflection for data object analysis?
- Reflection adds overhead during development, but the package mitigates this with caching via `php artisan data:cache-structures`. In production, this command pre-compiles data object structures, making runtime performance negligible. For serverless or CI environments, cache structures early in the pipeline.
- How does TypeScript generation work, and can it handle API versioning?
- The package auto-generates TypeScript interfaces from your data objects, reducing manual effort. For API versioning, you’ll need to manage TypeScript files manually (e.g., by versioning the generated files or using a build script). The generated types reflect your PHP data objects, so breaking changes will require updates to both backend and frontend.
- Will laravel-data work with Laravel’s Eloquent models, or is it only for API responses?
- It works with both. You can use data objects to validate input before saving to Eloquent models or to serialize model data for APIs. The package integrates with Eloquent’s casting system and supports lazy properties for partial transforms, making it versatile for both persistence and API layers.
- Are there any limitations with lazy properties or partial transforms?
- Lazy properties are useful for partial transforms but require explicit definition in your data object. They’re not automatically inferred, so you must mark properties with `#[Lazy]` or configure them manually. This ensures clarity but adds a small upfront cost for setup.
- How does laravel-data handle nested data objects or relationships?
- Nested data objects are fully supported. You can define relationships within data objects using other data classes, and the package will handle validation and serialization recursively. For Eloquent relationships, use the `resolveUsing()` method to transform related data into nested data objects.
- What Laravel and PHP versions are required, and are there breaking changes between versions?
- The package requires PHP 8.1+ and Laravel 9+. Version 4.x is stable, but breaking changes may occur in major updates. Always check the [changelog](https://github.com/spatie/laravel-data/blob/main/CHANGELOG.md) before upgrading. The team aims for backward compatibility but reserves the right to deprecate features.
- Can I use laravel-data for GraphQL APIs, or is it REST-only?
- While primarily designed for REST APIs, laravel-data can also work with GraphQL. Use it to define input types and validate GraphQL mutations/resolvers. For output types, leverage the serialization features to transform data objects into GraphQL responses. The TypeScript generation is especially useful for GraphQL schemas.