Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[6.x] Allow response to return first view #30651

Merged
merged 1 commit into from
Nov 22, 2019
Merged

[6.x] Allow response to return first view #30651

merged 1 commit into from
Nov 22, 2019

Conversation

browner12
Copy link
Contributor

There are currently a couple ways to return a view. The simple standard way is:

return view('my/view', ['data']);

If you need to customize the response a little you can tweak it to this:

return response()->view('my/view, ['data'], 404, ['headers']);

Some code takes advantage of the ability to pass an array of views, and return the first one that exists.

return view()->first(['my/view1', 'my/view2'], ['data']);

It would be nice to be able to manipulate the response status and headers, but also use the view first functionality.

I'm proposing allowing response()->view() to accept either a string or array as the first parameter. If the first parameter is a string, it will behave as it does currently. If it receives an array, it will use the view first logic.

return response()->view(['my/view1', 'my/view2'], ['data'], 404, ['headers']);

If we're uncomfortable adding some magic to this method, I also considered making it a separate method on the ResponseFactory so it would be called as:

return response()->viewFirst(['my/view1', 'my/view2'], ['data'], 404, ['headers']);

which I could switch to.

I was also having trouble locating where tests are for this logic. If someone could point me in the right direction that would be appreciated.

currently we cannot manipulate the status code if we want to return the first view in a list.

this allows us to pass an array to `response()->view([view], [data], 404, [headers])`
@taylorotwell taylorotwell merged commit e0d4aa3 into laravel:6.x Nov 22, 2019
taylorotwell pushed a commit that referenced this pull request Dec 4, 2019
this goes along with PR #30651 .

I'm not sure what our practice is for changes like this on an interface.... I'm not technically changing any of the code, just a docblock, so is it safe to send to 6.x?
@browner12 browner12 deleted the patch-3 branch January 29, 2020 21:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants