I would still think laraveldaily’s method is worth looking at instead of a single line, because I remembered spending time figuring how to use carbon’s method to create, save to database and display back, so knowing the in-outs will help a lot
I like this syntax, functional programming is very elegant and I like the fact the logic is held in a single structure. Instead of being methods on the class itself, they are part of the attribute which makes sense. I will have to look into this more but I wonder if this approach could benefit from hot-swapping the attribute accessor and mutator. E.g. in your protected function you can check various parameters of your code and then return the attribute with different callbacks depending on your needs. I think generally this new approach is better and reminds me of how other languages handle protected variables e.g. in Swift / C# accessors and mutators function similarly to this though with cleaner syntax due to being a language feature.
@@PunyFlash I wouldn't worry about what many hiring managers say. In my experience they can be very opinionated, and quite distanced from reality and accepted best practices. Usually you're better off avoiding a role with incompetent people (unless they're humble enough to know they need other's knowledge). I think the only way they'd be unreadable is if you're not keeping up with the language progression, if that's the case then it's really your fault rather than the arrow function's! Sure 'fn' is less explicit than 'function' but I still think it's fairly obvious and easy to read.
I've learned a lot from you in such a short time. Thanks a lot. I haven't fully switched to this new approach, at least for the getter/accessor part, because I haven't found a way to not loose access to the original attribute value. I mean, the one that hasn't been modified by the accessor mechanism. At least with the getXXXAttribute() approach you can add a new attribute with a different name and you don't loose access to the original attribute value.
I hope the old method doesn't go away. I like this new method for simple cases of setting custom casts. But there are sometimes where there is more logic behind the accessor and/or mutator and I think it's cleaner to separate them into their own methods, particularly when its not just a single line return. I also wonder will this new method work if I only supply just a getter or just a setter, or if it requires both to be defined. For example I define a getter but no setter to create a psudo field that doesn't actually exist in the DB. I do that a lot to create a separate property for a display version of a value versus the calculable version (for example with currency having an integer in cents for storing/calculating on say an 'amount' property, but having a getter to make a formatted string for display using a made up property like 'amount_display').
1:39 function startDate() { get: $foo; set: $bar; } confused me. I did not know that syntax from PHP 7.4 and indeed, that is not valid code. The working code is new Attribute(get: $foo, set: $bar) using PHP 8 named function arguments as shown in 2:20
Don't you lose any form of intellisense on this now? Or can you treat attribute like a genric in the docblock? (@returns Attribute) I suppose you can still document the class to have the correct type for the property.
I like that Laravel is going more towards the C# way of doing things, but it seems this can ONLY be done with Models? Is that correct? This is a Laravel specific implementation and not a PHP 8 implementation?
Mh, I mean I get his point, but it seems kinda less maintainable to me. Sure you can argument that you can see everything in two lines but I learned sometimes its better to have own functions for this so your brain works internally faster. Idk probably a personal opinion... I would probably accept both but I would rather still inplement the old way 🤔
The problem of eloquent that everything has separate method for itself: attributes, scopes, relations etc. In bigger projects models tend to be highly overloaded of random stuff which is harder to maintain. If you don't like arrow functions you always can use closure which is same and at least keep your attribute stuff within 1 method
Nice video, but, what if i want to cast this attribute, or better said, i have it casted as date? im having this error and i dont know hot to solve it.
I like this approach, it's more elegant in deed. I have a question though, how can we add a custom field to the model? Like when we have first_name and last_name fields in the database and we want to have the full_name attribute by joining the first two fields.
I followed you on Laracast aswell, Love your content btw... Just a question if you have a table "unit_price" in the migrations and a "tax" table. if i calc the tax amount how do a save it in the db ? because i get the tax amount witch is correct but it does not save in the db, sorry im still learning programming
I have only one question. Why Laravel hates my code? I had a model with field profit. And don't like Laravel's magic when I can call $model->profit to get the value. So I create a real method to call it $model->profit() and it returns a Decial object. But with this update, my method does not work anymore. Because it should return an Attribute. So the changes are great but I think you should not do something like this in minor updates. Laravel 9 - sure, no problem. But updating Laravel 8 I expect my code to still work.
I'm sorry that Laravel broke your code. But, in all fairness, you created your method against the typical Laravel conventions, it's quite surprising to me that method with the same name as field didn't override/break anything previously.
@@LaravelDaily Yeap, that's true. I had to respect the Laravel too. Since I need access to a mutated value I had to create a getProfitAttribute method. I've just tried to use a "safe" way and use a method that is not called inside a model. But I was wrong :)
Sir! Сould you please make another great tutorial video about elegant way to filter and sort data in "api routes" with "index" method with optional query params? For example: /products?orderBy=created_at&order=desc&created_at>=somedate&created_at
My controller start to look not elegant and not pretty readable when I try add functional as above even I use Form Reqests. Validations are required to prevent injections and prevent DB overload with big limit value.
I have a video on a similar topic, in my latest refactoring course: laraveldaily.teachable.com/courses/laravel-refactoring-examples/lectures/36715594 If you need more details than that one, it's your individual case so I can't reproduce it easily and make a tutorial, without full code example.
I like and hate this aproach. The usage of named arguments in the docs will be a pain for people using PHP 7.4 and below. I dont think this is a thing that everyone knows, but it looks fancy.
I might be wrong but if you are using PHP 7.x I would have thought you'd also be using Laravel 7.x? The versions are kinda coupled so that if you're using PHP 5.6 you'd likely use Laravel 5.6 etc. The docs are still available for all older versions of Laravel, I think it's great to make use of latest language features in latest framework release, I love many of the new PHP 8 features and I'd like to see them implemented more fully into Laravel.
@@fredhair I am still on PHP 7.4 but I can install the newest Laravel version. It wont be possible anymore with Laravel 9, but till now it is possible and that is the problem I see with features like this, where he is using named parameters so that the source code looks good on the docs (you can still use it in PHP 7.4, but without named arguments), but if the dev dont know about this will eventually have to inform about it or it wont work at all.
@@JohnnyBigodes I would have thought it's the developer's responsibility to know a bit about the language they're using. If you don't know your language you can't blame anyone else for your own lack of knowledge. I don't see what the problem is, this is the way things work as new language features come out newer framework versions make use of them. It's not as if this feature requires you to use the very latest PHP version, but as with many things, the later language you have the nicer the syntax can be / the more optional extras you have. You can't expect the latest frameworks to be totally backwards compatible with the oldest language versions, that's just not how things go.
No, will not be using this. Appreciate the option, but IMHO it is less readable, and I prefer to keep them separate. Most importantly, we've got several hundred of these across our apps, certainly not going to incur cost just to change to sugar. Unfortunate the docs will change - that means we have to train new devs into something that was standard until now. Not a big deal for one thing... but that creeps up on you when supporting legacy code bases.
For single line get / set this is nice. I bet ppl will separate the get and set into their own methods when they require multiple lines of code.
Use traits or services instead of adding this directly to the model. :)
I would still think laraveldaily’s method is worth looking at instead of a single line, because I remembered spending time figuring how to use carbon’s method to create, save to database and display back, so knowing the in-outs will help a lot
use anonymous functions
I like this syntax, functional programming is very elegant and I like the fact the logic is held in a single structure. Instead of being methods on the class itself, they are part of the attribute which makes sense. I will have to look into this more but I wonder if this approach could benefit from hot-swapping the attribute accessor and mutator. E.g. in your protected function you can check various parameters of your code and then return the attribute with different callbacks depending on your needs. I think generally this new approach is better and reminds me of how other languages handle protected variables e.g. in Swift / C# accessors and mutators function similarly to this though with cleaner syntax due to being a language feature.
I remember the day when company have not hired my telling that arrow functions are not readable
@@PunyFlash I wouldn't worry about what many hiring managers say. In my experience they can be very opinionated, and quite distanced from reality and accepted best practices. Usually you're better off avoiding a role with incompetent people (unless they're humble enough to know they need other's knowledge). I think the only way they'd be unreadable is if you're not keeping up with the language progression, if that's the case then it's really your fault rather than the arrow function's! Sure 'fn' is less explicit than 'function' but I still think it's fairly obvious and easy to read.
I've learned a lot from you in such a short time. Thanks a lot.
I haven't fully switched to this new approach, at least for the getter/accessor part, because I haven't found a way to not loose access to the original attribute value. I mean, the one that hasn't been modified by the accessor mechanism. At least with the getXXXAttribute() approach you can add a new attribute with a different name and you don't loose access to the original attribute value.
Like vue computed get set, shorter and nicer. Loved it thanks for the update!
The type of change that will become the code more elegant and readable
Feels like Vue's computed models (i.e. Computed property with getter and setter)
Much cleaner than vue though due to JS limitations.
Definitely am using it. It's good enhancement and shorter code.
I like it. Mostly for the shortened function name.
Cool use of PHP8 named arguments.
yeah i like this way, looks much clean, nice video
I hope the old method doesn't go away. I like this new method for simple cases of setting custom casts. But there are sometimes where there is more logic behind the accessor and/or mutator and I think it's cleaner to separate them into their own methods, particularly when its not just a single line return.
I also wonder will this new method work if I only supply just a getter or just a setter, or if it requires both to be defined. For example I define a getter but no setter to create a psudo field that doesn't actually exist in the DB. I do that a lot to create a separate property for a display version of a value versus the calculable version (for example with currency having an integer in cents for storing/calculating on say an 'amount' property, but having a getter to make a formatted string for display using a made up property like 'amount_display').
Yes you can specify one of them, for more details please read the PR by Taylor
1:39 function startDate() { get: $foo; set: $bar; } confused me. I did not know that syntax from PHP 7.4 and indeed, that is not valid code. The working code is new Attribute(get: $foo, set: $bar) using PHP 8 named function arguments as shown in 2:20
Don't you lose any form of intellisense on this now? Or can you treat attribute like a genric in the docblock? (@returns Attribute)
I suppose you can still document the class to have the correct type for the property.
no idea, sounds like a good tool to have either ways, cant hurt to have extra options
I like that Laravel is going more towards the C# way of doing things, but it seems this can ONLY be done with Models? Is that correct?
This is a Laravel specific implementation and not a PHP 8 implementation?
I'm impressed
Mh, I mean I get his point, but it seems kinda less maintainable to me. Sure you can argument that you can see everything in two lines but I learned sometimes its better to have own functions for this so your brain works internally faster. Idk probably a personal opinion... I would probably accept both but I would rather still inplement the old way 🤔
Yeah. I totally agree. Accessors and Mutators sometimes have very different logic. Putting them together looks a little bit clumsy in some cases
The problem of eloquent that everything has separate method for itself: attributes, scopes, relations etc. In bigger projects models tend to be highly overloaded of random stuff which is harder to maintain. If you don't like arrow functions you always can use closure which is same and at least keep your attribute stuff within 1 method
You are still able to separate both into two methods.
Nice video, but, what if i want to cast this attribute, or better said, i have it casted as date? im having this error and i dont know hot to solve it.
add casts in your model
protected $casts = [
'starting_date' => 'date',
'ending_date' => 'date',
];
I like this approach, it's more elegant in deed. I have a question though, how can we add a custom field to the model?
Like when we have first_name and last_name fields in the database and we want to have the full_name attribute by joining the first two fields.
Well it's the same thing, you just define the attribute full_name() as a function with get/set.
Cool! Thank you!
Will your quickadminpanel be updated to reflect this method on generated code?
No, it's not in plans, because we need to keep the code working for all the older panels and older Laravel versions.
I followed you on Laracast aswell, Love your content btw... Just a question if you have a table "unit_price" in the migrations and a "tax" table. if i calc the tax amount how do a save it in the db ? because i get the tax amount witch is correct but it does not save in the db, sorry im still learning programming
Thanks a lot !!!
I like this new method. :)
Why didn't you use the Laravel method to parse dates directly, thought?
What do you mean "Laravel method"?
Can you tell me Which package was used to build the DataTable?
Yajra datatables
I would use it.
kinda javascripty, but i liked it, and definitely would use it!
More like java and friends. I love it
For me old way was more readable.
Thanks
I have only one question. Why Laravel hates my code?
I had a model with field profit. And don't like Laravel's magic when I can call $model->profit to get the value. So I create a real method to call it $model->profit() and it returns a Decial object. But with this update, my method does not work anymore. Because it should return an Attribute.
So the changes are great but I think you should not do something like this in minor updates. Laravel 9 - sure, no problem. But updating Laravel 8 I expect my code to still work.
I'm sorry that Laravel broke your code. But, in all fairness, you created your method against the typical Laravel conventions, it's quite surprising to me that method with the same name as field didn't override/break anything previously.
@@LaravelDaily Yeap, that's true. I had to respect the Laravel too. Since I need access to a mutated value I had to create a getProfitAttribute method. I've just tried to use a "safe" way and use a method that is not called inside a model. But I was wrong :)
I like it
Nice
ّI don't use the new syntax because it is less readable.
You know what, I never use the syntax this->attribute. I never know this syntax acceptable. Perhaps I lacked of experience.
Yep, you can just call $this->myAttribute as Laravel will convert this.
Great news, I didn't like the old version
Actually C# in Laravel LOL
kinda lit if you ask me.
@@carterdee7084 lit what?
@@koldovalnya i like both languages but i prefer php. Seeing some similarities makes me happy
@@carterdee7084 Aaah, hehe, that's good :)
prefer old syle.
Sir! Сould you please make another great tutorial video about elegant way to filter and sort data in "api routes" with "index" method with optional query params?
For example: /products?orderBy=created_at&order=desc&created_at>=somedate&created_at
My controller start to look not elegant and not pretty readable when I try add functional as above even I use Form Reqests. Validations are required to prevent injections and prevent DB overload with big limit value.
I have a video on a similar topic, in my latest refactoring course: laraveldaily.teachable.com/courses/laravel-refactoring-examples/lectures/36715594
If you need more details than that one, it's your individual case so I can't reproduce it easily and make a tutorial, without full code example.
I like and hate this aproach. The usage of named arguments in the docs will be a pain for people using PHP 7.4 and below. I dont think this is a thing that everyone knows, but it looks fancy.
7.4 and below are out of the official support already, so those people are kind of "on their own".
I might be wrong but if you are using PHP 7.x I would have thought you'd also be using Laravel 7.x? The versions are kinda coupled so that if you're using PHP 5.6 you'd likely use Laravel 5.6 etc. The docs are still available for all older versions of Laravel, I think it's great to make use of latest language features in latest framework release, I love many of the new PHP 8 features and I'd like to see them implemented more fully into Laravel.
@@fredhair I am still on PHP 7.4 but I can install the newest Laravel version. It wont be possible anymore with Laravel 9, but till now it is possible and that is the problem I see with features like this, where he is using named parameters so that the source code looks good on the docs (you can still use it in PHP 7.4, but without named arguments), but if the dev dont know about this will eventually have to inform about it or it wont work at all.
@@JohnnyBigodes I would have thought it's the developer's responsibility to know a bit about the language they're using. If you don't know your language you can't blame anyone else for your own lack of knowledge. I don't see what the problem is, this is the way things work as new language features come out newer framework versions make use of them. It's not as if this feature requires you to use the very latest PHP version, but as with many things, the later language you have the nicer the syntax can be / the more optional extras you have. You can't expect the latest frameworks to be totally backwards compatible with the oldest language versions, that's just not how things go.
420 🍧
No, will not be using this. Appreciate the option, but IMHO it is less readable, and I prefer to keep them separate. Most importantly, we've got several hundred of these across our apps, certainly not going to incur cost just to change to sugar. Unfortunate the docs will change - that means we have to train new devs into something that was standard until now. Not a big deal for one thing... but that creeps up on you when supporting legacy code bases.