Laravel 10.1: What Controllers Should Return By Default?

[@flobbos]

I think Taylor made the right decision. Let people decide if they want to add return types and what kind. Otherwise you run into the super annoying side effect of having to change the predefined types every time as you mentioned.

[@kareemlateefyomi8690]

Yes I agree, many other framework gives us that Nestjs for example

[@brianochieng5904]

I respect you more for they way you handle 'regretful' moments, especially at the end, when you saying you'd work on how to convey your sentiments, that is top-tier man. Bravo!!

[@Ajcmaster]

Why not also add a flag to artisan to add the return type? Could have some default ones to cover the commons and also let you specify the complete path to a custom class.

[@davidgutierrez3312]

That's what I was thinking too

[@ArjonJasonCastro]

I also thought of this but this will additional code overhead and maintenance to the make command, thus, not the simplest solution. This is more fit as a package 😉

[@mycreativetech]

Once again great job. When I saw the laravel 10 update I was thinking that these return type should not be included, and now thanks to you that they have changed and removed this.♥

[@unarmedwombat]

The issue comes down to whether a framework is there to help you develop solutions or to constrain you to a particular view on what is 'good practice'

[@angelHighTech]

I think what i would liked to find is a commented section that's provide me a link to explain what can I add to optimize my response as new développer it would help me a lot to understand quickly the benefits and the use of those responses !

[@JeremyStreich]

So, returning a rendered blade file is View for displaying blade files as rendered HTML. Returning JSON can either be a JSON string, a Model, a Resource or ResouceCollection (and the framework generates the Response object) or a Response object. Resouce is useful for formatting fields, returning a Model is easy/quick. You can return a response()->file(...) to pass out a file from storage (or elsewhere on the server). You can set the headers yourself using PHP header functions and return the raw contents of file/image/data. I think the problem is that Laravel has been handling the type "magically" for so long people don't really think about the type returned to the router unless they have issues. Likewise, you can return raw HTML or text, and it gets passed out as raw HTML or text. Inertia also has a \Inertia\Response, if you're using it. Hence why simply : Response|View isn't going to cut it.... but an interface makes the most sense to me.

[@cardboarddignity]

In my project, I have even 3 types of controller: simple one that returns View, RPC Controller that returns JsonResponse|View, and API. This is tge case when it is better for you to decide what you want to return

[@mayanksgajjar]

Its based on the developers but I think, while generating controller, they can give options like for which tech stack you are generating controller for, for ex. Inertia, Blade, etc and based on that they can add return type in controllers method.

[@lwandilerozani8592]

Possible better solution to resolve the squabble that was, but since Laravel is originally more PHP than JS let's maybe limit that solution to the JS frameworks.

[@MarijanKopcic]

Keep tweeting about this kind of things please! You are doing great job! Laravel is moving to fast, and Taylor has made some "strange" decisions regarding framework.

[@TheShadetheory]

I like to return Renderable in web controllers and I believe the Symfony foundation response in API controllers so I guess I'm more of a fan of interfaces or parent classes I was never a fan of the whole App | Factory | view stuff. I'm not a fan of mixed I guess it does serve the purpose but it's so unspecific that I think no default return type is the better option. I appreciate you using your platform to help influence greatness in the laravel community

[@TravisFont]

The problem is in the view presenter. This layer should always gather a response, and depending on that response display a view, json, xml, etc. This will require a bit of restructuring in Laravel, but will remove this mixed which is useless and shows that there’s a structure problem.

[@wasiurrahman1447]

Very useful video thank you

[@KastsEcho]

Honestly, the best option was either Taylor's second PR related to this with the Responsible interface or to do union types. "mixed" was never the right answer since it goes completely against the point of having a return type. Laravel 10's main hype was embracing return types with the required PHP version being 8.1 or later; and Taylor's final decision took that away from the default stubs for Controllers. Now we pay the price by having to manually re-add the return types to the controller stubs for every project going forward instead of them being there out-of-the-box.

[@dashcharger24]

In Typescript unknown exists. I think it would fit perfectly, as you don't know yet what it should return.

[@JeremyStreich]

@@dashcharger24 That's what Mixed would have been.

[@TrikNgonlen]

Return the writing style to previous versions is good decision made by the author. It will help a lot for the beginner who still struggle learning Laravel from version 8 or 9. Even, in my opinion, it will help more advance-level of Laravel lovers to not doing extra "work" for their new Laravel project.

[@Niboros]

Thank you for being considerdate about your actions, but I'm also happy and grateful you are just you tho. :) Keep up the good work.

[@ChorumTheDevourer]

I think that this actions of Taylor is not correct cuz he can move return type in controller into the generator command. It can be like this: artisan make:controller WhateverController --return=view|response|whatever. If you don't pass this param it can generate default type. It will be more correct than remove returning type. It is not a php8 way I think.

[@cloudplayro]

Isn't the view() a "response" at some level? You can use `return response()->view()` i

[@jasonpeters9532]

I think all the opinions are valid for this. Personally I do prefer the return types to be there by default. Yes can be a bit annoying to always have to change them to suit your project. It would be nice if the types would be set based on the project and controller type. For example if the project is initialized with or breeze is installed the controllers are created with sensible default return types like '\Inertia\Response' on the index() method of a resource controller - but we run into again having to change them when required by the project needs - so manually adding them is not a huge hassle

[@ArjonJasonCastro]

Your tweet produced good and healthy friction.

[@jrxsabre6419]

Excuse me sir, May I ask you. Which VS code extension you use to show to type of the code such as you have view syntax then VS Code show the word that syntax is view (example: return view (view: 'user.index,...) ) something like this. Thank you sir.

[@LaravelDaily]

I use phpstorm, not vscode

[@ItsDigiUtime]

I think setting it to mixed by default is fine, but it should not stay like this. Say the developer implements the functionality, they should then appropriately change the mixed type to whatever they actually want to return. Perhaps an IDE should be able to recommend the developer to change the mixed type to the more appropriate one?

[@linasgutauskas5528]

What would be advantages of no-return type vs mixed?

[@LaravelDaily]

No mixed feelings :)

[@jcc5018]

My problem with this push for return types is That as someone still fairly new to programming, I don't really know what all the options are for the different types. On my own, I would never have known if something needs a response, or void, or mixed. etc. Some kinda make sense when they are present already, but how would someone new to programming know what type something needs to be and the verbiage needed for the desired result. Void vs empty or null for example? Is there a resource that lists theses possibilities with examples as to their usage?

[@LaravelDaily]

I will rephrase your question and tell you this: if you don't specifically know what your method should return, you should probably don't return-type anything.

[@jcc5018]

@@LaravelDaily As long as it doesn't get to a point where a return type is required, I'm ok with that

[@nerisonpitogo3717]

Great Video. Can you make a video on how to upload file to OneDrive using Laravel?

[@LaravelDaily]

I don't use onedrive myself so can't make a video about it

[@mahoke]

I'm just curious, what is the purple star/sun browser extension for?

[@yungifez]

Feel kind of weird seeing Povilas talk about my comment on the laravel framework itself Who would have thought I'd be commenting on the framework itself when I started with Kara 2 years ago

[@jediampm]

Hi, the problem was not Response Type return but the implementation itself type was bad. I you look at Symfony framework you dont have this kind of problem. In symfony a return Response type is anything that you return with content type: json, string, html, view, etc. Laravel is not taking advantages of latest features of the language or at least take too long too apply it like symfony and then happen this bad implementation. And this problem just demonstrate few problems the creator and the team, like dont doing some research and comparing with frameworks like symfony ( since they use a lot of their components) and make no sense commit this kind of "feature" before asking to the community about their thoughts.

[@dashcharger24]

In theorie a controller can even return void, I'm not saying it should, but its possible. I don't njnt, u usually don't use stubs anyway.

[@degagnemarc]

I think if we want controllers to return something by default, it should probably return what is the most used in the community, probably views. In the case of being neutral then what was before and what it reverted to, nothing, is fine. One way or another changes will have to be done to adapt it to the current project needs. Just make it to the most common uses!

[@bboydarknesz]

return mixed is killing the return type. It was just like return whatever you want so useless. recently my team add return type View in controller and then error boom everywhere because some are return as RedirectResponse, or Response. I know, i should add more test, but the controller method has many things happen. yeah, sometimes adding return type is a kill especially that method is mixed return like in controller method.

[@pokeripper9707]

What is even the possitive effect of adding a return type here like "View"?

[@LaravelDaily]

PHP will throw an error if you (or anyone in the future) will try to return something else than View.

[@Syed_haze]

my humble request to laravel please don't consider about only api making i am expecting laravel to be the best full stack framework and thank god povi sir found that really I don't understand that concept now back to form is much more appreciated keep coding...

[@Novica89]

Make a setting in the app.config or similar config file that says "resource_controllers_return_type" and have that value set to default of "mixed" and you can update it to some set of predefined values like "json" or "response" etc. If you do, your stubs will now have that response type in them. Done

[@THEunderscoreJOKE]

I think the obvious correct conclusion is to return mixed. It's exactly what the mixed keyword was created for. Not sure why there's so much debate over this.

[@Diego-eb9we]

I completely agree with you. While it's always possible to change the return type later, not including a return statement at all is a big mistake. Using Mixed return is clearly the best option, especially for beginners who are still getting used to the habit of always adding a return statement. With Mixed, they have the flexibility to return any data type, without compromising the integrity of their code.

[@LaravelDaily]

It's debatable whether beginners wouldn't get used to just return MIXED everywhere, without thinking :)

[@billionsjoel]

I believe your decision to tweet about the matter was justified. It helped expedite the resolution process and provided us with an improved version to work with. We appreciate your contribution and assistance.

[@1234matthewjohnson]

the trouble is the controllers can return anything, so a response return type isnt correct, I feel like a mixed return type is more correct than nothing as it encourages new users to get into the habbit of doing it.

[@brunobellomunhoz]

Exactly, that's how it think as well. It's fine if you don't use it, but it simply being there reminds you to do a good practice.

[@KirillHybrid-f4f]

The idea of return of response is a good idea to "standarsize" what the code returns in any case. I think it was good implementation, you always able to customize this behavior. This would help to improve good practices.

[@basherdesigns]

I see this whole matter a win win for the community! It makes for a better Laravel if devs can ask questions or have opinions and Taylor listens and is open minded, which he was and I agree he did the right thing. Makes me love Laravel even more! 👍

[@marcincook]

In My opinion stubs for controler is only simle skeleton, faster write code, generate file, class only from command line. But controller is closer for business logick. If your logick except view you must return View if redirect you must return RedirectResponse. This is not Universal for all project. This is correct Taylor decision. Stubs is skeleton, you must coding self. If your project has 99% the same logick of return, publish stubs and change this in stub, and you have concret skeleton for your project or preferences...

[@guillermofelipetti2593]

I dunno why mixed return type is wrong

[@ricko13]

Using the *mixed* type means using a "wildcard", and it defeats the purpose of using types. If you have ever used TypeScript, it is like using the *any* type

[@guillermofelipetti2593]

@@ricko13 In my personal opinion is better to have it type as "mixed" than no type at all. The developer is free to choose the response that he wants

[@martinlionel7487]

I think controler return HTTP response or not type return

[@dyhcdjvddhh421]

I never thought such inportant decisions are changed so lightly. Controllers returns are most used part of framework.

[@joshuaebhoria8046]

what if we can specify what we want the controller should return while running the artisan command 🤓

[@LaravelDaily]

Still too many options.

[@Flankymanga]

I mean people have very strong opinions about such trivial things...One does not know if to laugh or to cry... In general I would say that: Don't try to fix things that are not broken?

[@MrDragos360]

Laravel is going way too fast. Last year I was using Laravel 8 and now it's already at 10.1. Compared to Net Core and Spring that update way slower this is crazy. Is there a reason why it's chaning so much so faster ? Also are the old version like 7 or 8 still relevant ?

[@LaravelDaily]

Old versions are still relevant, you can still use them, no worries. And it's not really fast, it's one major version per year, this year it's Laravel 10 and next year will be Laravel 11.

[@MrDragos360]

@@LaravelDaily thank you. I have 2 projects in laravel 7 and one in laravel 8, both live stuff( 2 web stores, and 1 medical clinic appointments manager system). Do you think that I should updagre them to laravel 10 ? From this video the ideea of having a forced return for controllers sound really great, it makes it closer to net core.

[@fx-willem-jan]

@@MrDragos360 I would definitly recommend updating your framework. Better do it now than later. Laravel has great upgrade guides, and if you have tests written, you can easily check breaking changes. Upgrades also get more difficult over time with older projects. I would schedule a big update for your projects every 3 to 6 months, since these upgrades probably won't event take much time. If you wait several years with an upgrade, you might run into the issue of old unsupported php or framework versions, breaking changes when upgrading and it will be a big head ache

[@MrDragos360]

​@@fx-willem-jan but is there a point in upgrading if everything works fine ? I don't use automated test, I manualy test what I do :)

[@fx-willem-jan]

@@MrDragos360 there comes a point when the current version of the framework will not be supported anymore in a couple of years from now. waiting untill that point to upgrade will most likely cause more issues than small upgrades over time. But of course at the end it still is all up to you. If the project will only run for one year, it is probably not worth it

[@Diego-eb9we]

I really don't understand why people don't like mixed return, I mean, you always have to return something, be this something whatever you want other than void, so why are people complaining about mixed return? Can anyone enlighten me?

[@overhead4577]

Framework aim to do some things behind the scenes, like correctly serialize controller return data. Return type mixed is one of the best return types for controller) General interface would be an overhead

[@olorundaolaoluwa]

Yes , i do , Allow developers to decide what to return.

[@praffulpanwar]

Returning : JsonResponse|WhateverResource or sometimes : JsonResponse|AnonymousResourceCollection for APIs

[@mostafamohamed9102]

Could you tell me please how to change session for different prefix Ex: /Mostafa has his own session /Ahmed has his own different session

[@albuslrc]

I prefer to be strict with the types, but the decision of Taylor does not bother me.

[@Novia5555]

Yea, I agree with Taylor tho...

[@grzesiekb9142]

If you care about your code you will add return types manualy. Hardcoding mixed was not a good idea. Now it is ok

[@Diego-eb9we]

If you care about your code, you should always be mindful of typing the return statement correctly. However, if you're not sure what type of data to return, using Mixed can be a good option. While it's better to be specific and type out the return data, using Mixed is still better than not returning anything at all - especially for beginners who may be unsure about the return data type. What do you think?

[@opeyemicoker9104]

It is great that things like this happen, it shows how great the Laravel community is.

[@prezire]

But isn't this the perfect combination? Response|View

[@boubaker86]

I think that this is the best decision, but adding an option in the make:controller command would be great (to choose between the old and the new stubs). Something like: make:controller WhatController --ressource -t

[@jhonatanatuesta5954]

Can You do Review to KrayinCRM ?

[@LaravelDaily]

I already have a few code examples from it, here: laraveldaily.com/code-examples/project/krayin-laravel-crm By "review", what do you mean exactly? It's not a quick package I can review. in 5 minutes in a video.

[@CyanidePierce90]

I think leaving it blank is the best option. It could confuse new devs as to what they are doing wrong if they're getting an error by default like for example if they return a view.

[@nicolas.chauvet]

I'm glad to see that Taylor is a real democrat!

[@MohAliii]

The issue here is that you call it a bug. I am not as proficient as you, but that's what could have upset Taylor. As for what I lean to, I guess all possible return types should have been put as a Union Type. And the developer could remove whatever he likes, but it still works if he does not.

[@asadbhatti4506]

I think type hinting something is better than nothing. this will make new laravel developers not use the feature at all and skip it. there should be some convention or structure to this controller because now some projects will have these type hints and some wont.

[@LaravelDaily]

By "some" convention, what convention would you actually suggest that would be ok for everyone? That's the point of this whole debate, and not an easy question.

[@PunyFlash]

I don't agree. Putting type hinting everywhere just so it present is overengineering. If controllers can return by fact anything, you should not force it to return only Response by default.

[@brianochieng5904]

@@LaravelDaily What if they gave the option to ask the developer the type of controller they want, just like it now happens in Breeze? After the make:controller, could they have the option to ask you if you'd like to have the return types, or whatever type hint you will need at that particular moment.

[@LaravelDaily]

Yes, one of the options, I will try to look at the ways to make it as a Pull Request.

[@LeandroAndrade2010]

The controller should have a return, just sort...

[@vickoalan]

yes, the controller should return anything

[@tiagotheoliveira]

Doesn't hurt anyone to change one word when needed. These people are so annoying!!!

[@LaravelDaily]

It's not one word. It's one word in multiple methods of multiple classes in multiple projects.

[@tiagotheoliveira]

@@LaravelDaily Still not a problem (for me), before (and now), people have to write manually for multiple classes in multiple projects anyway. Of course, people who cares about return types.

[@MomoDerDodo]

Because i return different things in every controller i removed the return types anyways so i like taylors decision

[@elmarzougui]

this is the Right decision,