[5.5] change how request only works and remove intersect

[themsaid]

This will make Request::only() work like Collection::only(). Currently these two methods are inconsistent with each other. This will bring them into harmony so that they behave the same.

Given the following payload:

{
    "name": "",
    "category": null,
    "level": 0
}

Output of request()->only('name', 'category', 'level', 'age') will be:

[
    "name"=> "",
    "category"=> null,
    "level"=> 0
]

Prior to this PR, age would have been included in the array returned by only.

[johnRivs]

Don't have any relevant feedback (other than 'I love it') but I wanted to mention how much I love all those red lines in the commit.

😍😍😍

[sixlive]

I think this makes total sense. Brings consistency and, what I feel, is what you would expect from the only method.

When I build an API that supports PATCH I almost always add a custom macro to add this exact behavior.

Awesome

[skyrpex]

I didn't know Request did that. I prefer the behavior that this PR brings to the framework.

[misenhower]

The old behavior can be useful when dealing with checkboxes since an unchecked checkbox will be completely absent from submitted form data (rather than being present and set to false or null, etc.). The old behavior lets you specify all the fields you want to update and ensures they're updated even if they are missing from the form post data.

I like the consistency that this change brings, but it might make certain situations a little more awkward. Is there another method that replicates the old behavior?

[boydcl]

Yes please, this is definitely the most logical way the only method should work. The way it works now (before this PR) prevents me from using it especially in handling PATCH requests.

When you think about it it doesn't make sense that a method called 'only' will create new values, it should do no more than filter existing values.

[taylorotwell]

@misenhower one suggestion I have mentioned internally is to have a pick method which replicates the old behavior to allow people to maintain the old behavior in their applications.

[misenhower]

@taylorotwell That sounds good to me. Would be good to have that on the Collection class as well for consistency 👍

[themsaid]

Following on @taylorotwell's comment, this will also make it easier for people while upgrading to just replace only() with pick() if they want to keep the old behaviour.

[taylorotwell]

This also introduces a change in behavior where only can't retrieve nested keys. We may want to still have that functionality.

[themsaid]

Right, will look into that.

[themsaid]

It now supported nested keys as well.

[laurencei]

@misenhower - as a side point you can solve your issue another way:

<input type="hidden" name="the_checkbox" value="0" />
<input type="checkbox" name="the_checkbox" value="1" />

That means an unchecked checkbox will still come through your form request as 0 - even though they are not ticked. I use this in all my projects - works flawlessly.

http://stackoverflow.com/a/476581/1317935

Might mean you can refactor your code to use that, rather than refactor to use the new pick().

Ping me on slack if you want to discuss further (dont want to derail this PR)

[juukie]

@laurencei that is a way to solve it but it feels akward to me.

I'd prefer to have the pick() method to be added so I don't have to mess with frontend code. Replacing only() with pick() in the backend will be a lot easier.

[misenhower]

@laurencei Yeah, that's a good option too, I've had to do that in a few situations as well. It works but feels a little hacky (and it adds duplicated fields to query strings if you're submitting via GET). Good to have both options available 😃

[Keoghan]

👍

[meyyappanv]

+1

[michaeldyrynda]

Not only consistency within similarly named methods in the framework, but more coherent behaviour. I think it a bit odd that telling a request you want only certain keys, and getting a key that doesn't exist is a bit rough.

👍

[JosephSilber]

Cool trick 👍

[taylorotwell]

Updated the $placeholder to just be an empty anonymous class since HTTP requests have no way to pass in an object like that and we can do a strict equality check. Even though it would be very rare to guess a str_random just feels safer since its now totally impossible.

[JosephSilber]

$placeholder = new stdClass; should also work, and would make StyleCI happy without another line break.

[pankitgami]

+1

[themsaid]

Switched to using stdClass.

[RDelorier]

One day this is going to happen 😌 #15758

[OwenMelbz]

Only something to consider from a "social responsibility" point of view.

Recently theres been a surge of tweets/blog posts, video tutorials including ones from @adamwathan suggesting the benefits of "Intersect"

Now removing it will lead to killing lots of recently released blog posts/resources which could confuse newcomers.

[michaeldyrynda]

Happens all the time, just means it's time for new blog content!

[ejunker]

@themsaid are you going to add the pick() method discussed in this issue? It would make it easier for people to upgrade because they could replace their uses of only() with pick() and not have to worry about their code breaking.

[vinterskogen]

@themsaid, are there any solutions of using intersect method with correct behavior in 5.4? In 5.4 intersect method doesn't work properly in come cases - check the issue #20315.

[kz]

@vinterskogen Given the recent changes with this topic, it's best to use a macro and wait for Laravel 5.5. You can find an example of a macro with a person's expected version of intersectOnly here: #15758 (comment)

[peter-dorn]

Not sure if I'm at the right place, but will this fix this problem as well:
When I pick rules from a FormRequest which contain a validation for an array as well, I get this strange wildcard as key in my output as well. Both for the only() and intersect() method.

$rules = [
            'title' => 'required|min:20',
            'channels' => 'min:1',
            'channels.*.account' => ‘required’
        ];

$request->all()

array:9 [▼
  "_method" => "PUT"
  "_token" => "BFcddbCGLshZtzB75XjjaM1LXAs4707zH49b4Li2"
  "title" => “Some Title“
  "channels" => array:2 [▼
    1 => array:1 [▼
      "account" => "1"
    ]
    2 => array:1 [▼
      "account" => "2"
    ]
  ]
]

$request->intersect(array_keys($rules));

array:5 [▼
  "title" => “Some Title“
  "channels" => array:3 [▼
    1 => array:1 [▼
      "account" => "1"
    ]
    2 => array:1 [▼
      "account" => "2"
    ]
    "*" => array:1 [▼
      "account" => array:2 [▶]
    ]
  ]
]

[arborrow]

I was cleaning up some code and had been using filled on a request to ensure that it was in fact filled.

    $donation->start_date = $request->filled('start_date') ? $request->input('start_date') : null;

In testing I noticed: Object of class DateTime could not be converted to string because the filled method expects a string.

In my case, I don't see any advantage to using filled. so I'm simply going to remove filled and go with:

    $donation->start_date = $request->input('start_date');

Nevertheless, I would have expected filled to continue to work; however, I suspect that casting start_date as a date in the Donation model explains the change in behavior (previously on the edit resource view I had renamed the form input name to start_date_only).

My question, for those with a greater understanding of how things ought to be, is would it be a helpful tweak or create an issue requesting to modify the filled method to properly handle a DateTime objects or would doing so encourage less than ideal programming? Alternatively, I wonder if an explanation on https://laravel.com/docs/8.x/requests to explain that the filled method will not work with a date would be helpful.