[8.x] Validated subsets

[taylorotwell]

Convenient methods for getting subsets of validated data.

$validator->safe()->only(['name', 'email']);
$validator->safe()->except([...]);

$formRequest->safe()->only([...]);
$formRequest->safe()->except([...]);

[taylorotwell]

Decided to change approach and add a new Illuminate\Contracts\Support\ValidatedData contract which I can use as a generic interface to indicate that a collection of data has been validated as "safe". This will open up some more interesting doors for me later on.

You can now call the safe method on a validator or form request to get an instance of Illuminate\Support\ValidatedInput which implements this interface.

[iksaku]

Loving it! It effectively resolves something I had to code just a few hours ago ⭐️

[franzliedke]

@taylorotwell Should the interface contain the only() and except() methods? 🤔

[amaelftah]

i have a question ... may i know why not bind the interface to the concrete ValidatedInput instance inside ValidationServiceProvider ... and here call app(ValidatedData::class, ['input' => $thsi->validated()])

[tpetry]

That's nice! And also changing the return type to the interface. I mean, we don't need the interface if the implementation is hardcoded to a specific class.

[timacdonald]

Any reason we aren't just hitting the Arr::only(), Arr::* method on all of these?

[taylorotwell]

I noticed that Request's InteractsWithInput had it's own implementation that I presume has some slightly different behavior than a plain Arr::only. Therefore, I just kept the implementation matching. I haven't dug into what the subtle differences between the two would be.

[SagarNaliyapara]

one difference that I can think of is passing * would return different result for both @timacdonald @taylorotwell

[timacdonald]

@ryangjchandler will appreciate this one

[ryangjchandler]

This is beautiful.

[timacdonald]

This is rad.

Only thing I would add to this is that it could be nice and also consistent to allow property style access on the ValidatedInput.

$request->safe()->name;

$request->safe('name');

This is already possible with array access $request->safe()['name'], but might be more consistent with other things in Laravel that also support individual property access out of the box.

Of course that could come in a follow up or something we implement in our own applications. Just a thought!

Thanks again!

[taylorotwell]

Added __get, __set, __isset, __unset support @timacdonald.

[taylorotwell]

@franzliedke the reason I didn't add those to the interface was the main use case I could think of for the interface was Eloquent mass-assignment operations, where you would simply be iterating through the data and hydrating a model without checking the fillable or guarded arrays. In that use case and similar use cases only iteration is needed.

[tpetry]

Wouldn't an immutable object make sense? A stict guarantee that ValidatedData is the unmodified result of a validator would sometimes be usefull i guess. What i mean is, changing a validated input may make it not the valid anymore.

[arcanedev-maroc]

@taylorotwell Any plan adding this feature in Illuminate\Foundation\Http\FormRequest ?

UPDATE: NVM, i've just checked the changed files. Thanks taylor ❤️

[arcanedev-maroc]

How about this instead:

return $this->validator->safe();

And you can remove the use statement after.

[geocfu]

@taylorotwell @timacdonald
Would you be able to elaborate with an example usage? I searched in the docs (both 8.x and Master) but I could not find an example or a mention of this new feature.

Thank you for your efforts!

[JosephSilber]

Any specific reason this isn't an actual collection?

(The only difference is the only method working on nested data, which we could easily add to the collection's method, or just override it here)