Creating a DTO with Livewire from array not working

[oliverbj]

I have a problem with generating a DTO from an array using Livewire v2. Below is my method:

public function getDocumentsProperty()
{
    //$documents = Http:: .... (This is received from a 3rd party API)
    $documents = Arr::get($documents, 'UniversalEvent.Event.AttachedDocumentCollection.AttachedDocument', []);


    return DocumentData::from($documents);
}

Then, this is how my DocumentData class looks like:

class DocumentData extends Data implements Wireable
{
    use WireableData;

    public function __construct(
        #[MapInputName('FileName')]
        public string $name,
        #[MapInputName('SaveDateUTC')]
        public Carbon $date,
        #[MapInputName('ImageData')]
        protected string $content,
    ) {
    }
}

But this gives me the following error:

Spatie\LaravelData\Resolvers\DataFromArrayResolver::Spatie\LaravelData\Resolvers{closure}(): Argument #1 ($parameter) must be of type Spatie\LaravelData\Support\DataParameter|Spatie\LaravelData\Support\DataProperty, null given, called in C:\laragon\www\shipcast\vendor\laravel\framework\src\Illuminate\Collections\Collection.php on line 819

What am I doing wrong?

[rubenvanassche]

The last parameter is protected, so we can't do anything with it. It should be public. The package is with the newest version we're releasing today a bit more robust in these cases.

[joelvh]

Hi @rubenvanassche,

Is there a way to use protected constructor args? We use this when instantiating objects to omit the property from JSON. Or is there an attribute we can add to a constructor arg to indicate it should be omitted when transformed to JSON/array?

Thanks!

[joelvh]

Just to be clear, I was wondering if what you alluded to in the "newest version" addressed this shortcoming in some way. Thanks.

[joelvh]

It's also worth noting that our workaround is to create the property on the class and setting the value in the constructor rather than promoting. However, it would be more consistent to be able to promote.

[rubenvanassche]

We're a bit more robust in error messages if I'm not mistaken. Protected paramaters are still ignored completely, maybe this is something we want to be able to configure in the future, saw someone with a similar question today. Only I don't have the time to implement such a thing so PR's are welcome.

I think someone is also working on a PR to make public properties automatically hidden based upon an attribute when transforming.

It's also worth noting that our workaround is to create the property on the class and setting the value in the constructor rather than promoting. However, it would be more consistent to be able to promote.

Nothing wrong with this in my opinion, we even advise you to use this approach for more complex default values.

[joelvh]

@rubenvanassche I was looking at the internals, but couldn't identify where exactly to try and support protected properties. But if I can get more familiar with the codebase to see where those are excluded, I will likely attempt a PR.

I didn't find the attribute solution you mentioned, but will keep an eye out. Thanks!