Reusable Data Objects for store and update endpoints

[raimidev]

Hello, I have a question that I couldn't find an answer to after searching in different repos, reading docs, and the laravel-data demo that you gave for this past Laracon (super excited about the v4 of the package btw!!).
The question is, and I guess it would be better for me if you could refer to an example of it being used, is there any way to reuse a data object that is being used in a store endpoint, in an update endpoint.
For example:

public function __construct(
#[MorphableRequest('required')]
public string $address1,
#[MorphableRequest('nullable')]
public string|Optional $address2,
#[MorphableRequest('required')]
public string $city,

    #[Max(2), MorphableRequest('required')]
    public string $state,

    #[Digits(5), MorphableRequest('required')]
    public string $zip,
) {
}

I have that previous Data Object, and it is currently being instantiated in the store controller method, and it is working perfectly, but if I want to support partial updates for the same resource, would I need to create a different Data Object where all the properties are Optional?
I tried to circumvent this by creating a custom ValidationAttribute that basically adds 'required' if the request method is Post, 'nullable' if the method is Put, and by default, it adds what you passed as an argument to the validation rules. The problem with this is that laravel-data is doing a two step validation, and the first step would basically run with the inferred rules, which means even if I add 'nullable' if the data type is: string $variable that field is going to be required in the payload that the Data Object is trying to be instantiated from.
Any suggestions? Someone has probably addressed this issue already, and I would be really interested in finding the approach that they followed. Thank you in advance.

[dominikdassow]

Hi there! Great to see that you're excited about the laravel-data package and where it's going, I am as well 😬

I'm using this package together with the laravel-typescript-transformer and they work great together. Having the different request data classes (for store and update) explicitly defined is the only way of getting proper TS types at the moment. Your idea could help in that scenario as long as the TS transformer package could account for that.

However, I think I actually prefer having explicitly defined data classes for this kind of request data, like store and update operations. They are essentially entry points to your application and your business logic. Explicitly defining which properties you expect for each of these operations is probably worth the effort in the long run. Overloading the data classes with more magic, like you mentioned, sounds like an abstraction at the wrong place to me.

[raimidev]

I agree with you 100%. After considering the cons of our approach, we decided that if we went through with it, we would actually be going against the main purpose of using laravel-data, which is to have strongly typed classes. The only downside is that you have to maintain at least 2 data objects per resource, but is a trade that we are willing to take. Thank you for your reply 😄.