How/When to Use Traits in Laravel: My Opinion 

Traits are PHP way of overcoming the inability to do multi-inheritance in a class so when you use a trait in a class you need to think of it as inheriting a super-class which is the trait in this case

traits are the way that php implements multiple inheritance which is not implemented, so you are absolutely right Povilas.

It's not about moving out the code, instead, it's about moving out (Separation) of logic. Keeping this in mind, use traits for moving some repeatable code and use some other classes (model or service, action, job whatever you say) to move/separate the logic.

I'm sorry but these people need to review the concept of MVC. Good content! You're completely right and these are simple architectural concepts.

Well explained, in my experience I completely agree with you. So many times I’ve seen traits used badly and when it comes to maintaining code it can be a nightmare. The hardest part is always deciding which class (model/service/trait) should be responsible for some functionality, that just comes with experience. Go with what makes most sense at the time and which option you find easiest to justify to your peers.

Agree completely. Traits are for code to be reused across different classes.

To me traits should act like small 'extensions' of a class, which will have a pretty high cohesion with the class that uses it. Laravel traits that are used in BaseController act more like helpers, that ease the usage of dispatching jobs, authorizing users, and so on. The problem is, we all have controllers that don't use none of these traits, but still load them. Solution - either make different BaseControllers, or use these traits in each of your controller. Spatie trait on the other hand, extends the functionality of particular class, whose logic rules are defined with an interface HasMedia. That makes huge difference with Laravel's helper traits. To me Laravel's method of using traits is a bit of a smell, I'd rather make different base controllers, or use trait in the particular controller, or even inject service as a dependency. The last option lets test your code much easier.

How I learned when to use trait in case of controller we are using and was easy to understand if example of HasCRUD trait . This trait has methods of resource controller and can be used in system which heavily rely on CRUD to make development task easier. As CRUD was concept well understood even among beginner this example helped me a lot.

Definitely, when refactoring code, so re-usable is refactored into traits, which adds additional power to classes.

Hi Povilas, I fully agree with you from a "coding theory" point of view. But on the other hand, personally I'm using Traits to add "view presenter" functionality to some of my models, which is kind of an abuse of the trait, but it is soo much cleaner and handier in the implementation. So I guess my final opinion would be to be a bit lenient on the use of traits. Main thing to keep in mind is to be consequent in your codebase. Don't use an Action once and a Trait in another case. But always refactor to traits, or always refactor to Actions. And additionally, stick to a clear naming, e.g. name your trait "OrderInvoiceAction" to make it more clear what kind of functionality it contains (or put it in a separate namespace like Traits/Actions)

your opinion works for me

I agree with your opinion 100%.

Hello teacher, the times I have used a trait it has been to add functionalities that can be used from various classes, for example, that "pushStatus" method, I would probably have it in a trait. I've even scoped traits, so filtering by status or things like that are features I can add to eloquent, just by using the trait and not declaring a scope for each model that requires it. I have used a translator, I hope everything is understood. :)

I used Traits on one of my microservice, but figure out something. If you add more than one trait in some cases there were some conflicts happening there. So refactor all traits into services and other things and after that, all work much better and without any conflicts. So Traits can be Ok but too many traits didn't good at all :)

Now I understand better with use case of trait

very useful thank you

extremely useful. thanks for your videos.

It a holy wars speaking about traits. I met people who say that this is a real evil, some one says trait is awesome. I have a positive attitude to everything, I don’t see anything bad in traits, but I understand that they are like a library to a class.

Hello Povilas, I agreed but why we can create helpers in laravel. Helpers can short code as well. we directly call helper function instead of importing trait in the model. why we should not use helper instead of trait.

Traits should, by design, be something reusable. E.g. if you use uuid instead of incrementing integers for Ids in you mordel. Then you can inherit the functionality into the models which should use that format for the identifier.

is it possible to update polymorphic relationships and update the model in a single query with eloquent or would you need to use DB:Raw for this?

Perfect!

Thanks

I think better way to use trait is that, it should be used where same code is repeated in different controller, it something that I used to follow concept like DRY.

rarely use traits, prefer use helpers instead

Fine

agree

I would have used traits only if there were multiple types of order. If you have one single order type, using a trait is overengeneering. IMHO of course.

Any knowlegde on Polymorphic Relationship event listeners? I have a Post and when its Polymorphic Status relationship updates via Post::find(1)->status()->sync(1) I wish to fire an event that sets the published_at if null and switches all the URL's in my markdown from private domain/files/id version to the public/uploads/filename.jpg version. It also seems that on relationships you cannot get dirty relationships correct? Or at least you cannot make relationships without saving to the database with polymorphic similair to fill() or make(). Any personal experiance with such a thing? if not ill just have to compare everything and fire stuff manually from the controller. (adding bulk, and sure bit more readable for a junior dev joining in (won't happen)) but anyway.

4:58 but why it needs to have `HasMedia` Interface implemented before using `InteractsWithMedia` trait?

Thanks for this video! It solved me a problem. I have a quick question, i am planning to create a new website from scratch of an existing one which is based on opencart. So what do you recommend, should i use the same tables as how opencart uses or migrate all the data totally to a new schema?

Agree that traits are not the replacement of services.

Traits are kind of polluting your code and shoting your own leg. There might be some cases where traits might be useful but in most cases they make stuff less readable, indirect and hard to test. My suggestion: when you're not sure if you should use a service class or a trait: use a service class.

Is repository pattern over-engineering in laravel ?

When you are trying to hard to come up with a trait, just use a service class. I have been bitten by traits in the past, but this is just my opinion.