[9.x] Added has and missing methods to ValidatedInput

[Sammyjo20]

This PR introduces two new methods to the Illuminate\Support\ValidatedInput class.

• has($keys)
• missing($keys)

These two methods are used to check the existence of validated input easily. For example, now with the $request->safe() method, I could now do:

$validatedName = $request->safe()->has('name'); // True
$validatedAge = $request->safe()->has('age') // False

$validatedName = $request->safe()->missing('name'); // False
$validatedAge = $request->safe()->missing('age') // True

You can also provide an array, and it will validate each key...

$validatedName = $request->safe()->has(['name', 'age']);

[Sammyjo20]

Is the updated correct, Dries?

[Sammyjo20]

I've also updated the other instances of array|mixed in the file for you 👍🏼

[Sammyjo20]

Self review complete

[Sammyjo20]

I also wanted to add a method to the FormRequest class, like $request->hasValidated($keys) or $request->validated($keys) but I wasn't sure if you guys would like that, what do you think?

[Neol3108]

I feel like missing is more Laravel-ish

[BrandonSurowiec]

I had the same thought, missing() is used as the method name when interacting with a plain request() instance.

https://github.com/laravel/framework/blob/9.x/src/Illuminate/Http/Concerns/InteractsWithInput.php#L220

[Sammyjo20]

I'll get that updated 👍🏼

[Sammyjo20]

I have changed the doesntHave to missing as I do agree it sounds more like Laravel's language, so I will update the description of the PR.

[Sammyjo20]

Hey guys, I'm just thinking - does this PR add value to the framework? I could have sworn I recently had a use-case where I wanted to check if something was validated. Surely if the data was provided, it has to be validated. This does double check that it was provided AND valid, but not sure if that's really helping.

Could this be sufficient, $request->has('input') / $request->filled('input')? Again, if the input has been provided it must have been validated.

I think it may have been because I was conditionally applying the rule in my rules() array. In that instance, it would be useful.

Edit; Also come to think of it, if people are using the validator outside of the FormRequest class, this would be very useful for people.

[taylorotwell]

@Sammyjo20 one thing I notice is the there could be a slight behavior difference between request->has and validatedInput->has... you use array_key_exists while request->has uses Arr::has under the hood. Thoughts?

[taylorotwell]

Please mark as ready for review after responding. Thanks.

[Sammyjo20]

Ah yes, good spot. I have switched it to use Arr::has() like the InteractsWithInput trait has.

From InteractsWithInput:

public function has($key)
{
    $keys = is_array($key) ? $key : func_get_args();

    $input = $this->all();

    foreach ($keys as $value) {
        if (! Arr::has($input, $value)) {
            return false;
        }
    }

    return true;
}

[matiaslauriti]

May I ask why is Laravel not requiring a type-hinted return?

For example, the has and missing could easily have : bool at the end:

public function has($key): bool;

public function missing($key): bool;

Why I am saying so? I see other tests and author's tests are using assertEquals for booleans, which means that if has or missing starts returning something that is not true or false, the tests would not fail nor the method itself would throw a PHP Fatal (allowing the Laravel team to fix this on a test).

public function has($keys)
{
    return null; // Example
}

$this->assertEquals(false, $inputA->missing('name')); // This passes because false == null

The fix would be to start using assertSame (valueA === valueB) and type-hint the return value (because we can in this case and we are allowing PHP 8.0+ on composer for Laravel 9.x).

public function has($keys): bool;

$this->assertSame(false, $inputA->missing('name'));

So, is there a why we are not doing so? I am asking so when I contribute in the near future I am already aware of this 👍

[matiaslauriti]

@driesvints

[Sammyjo20]

@matiaslauriti I was just keeping it consistent with the rest of the test. I assume it was written a while ago. I’d rather keep it consistent than make lots more changes to have to be reviewed. I agree though I prefer “assetTrue” and useful methods like that.

[driesvints]

We don't use return types right now in the codebase. We have no plans right now to add any.