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

Conversation

@browner12
Copy link
Contributor

browner12 commented Nov 21, 2019

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
2 checks passed
2 checks passed
continuous-integration/styleci/pr The analysis has passed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
browner12 added a commit to browner12/framework that referenced this pull request Dec 3, 2019
this goes along with PR laravel#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?
taylorotwell added 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?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.