Dive Deeper with Actions

[@relaxationtube2388]

Good lessons here. Perhaps it’s beyond the scope of this Larabit but putting those magic numbers (experience points) into an enum or some sort of experience class will definitely improve this workflow

[@gdogmalone]

GREAT, video. Learnt loads 🙌

[@dragoninfintyskull]

Full course on actions with test please….

[@ParisBenjaminsound]

Thanks

[@popforall]

What if I have a database transaction in some of my sub actions Should I add another transaction to the parent actions or what should I do?

[@obadaalzidi6452]

Thanks, that's great ! Just for clarity, shouldn't the AwardExperienceTest be a Unit test ?

[@VuTuanIT]

A unit test should be pure and not involve database transactions, otherwise, place it into feature tests

[@houseandhobby6971]

Oops I dropped in to learn about class action lawsuits to avoid the developer.

[@yoho403]

Wouldn't a trait be better in this case to avoid creating one time use objects?

[@shamwela_]

Why don't you just create a reusable function instead of creating "Action" classes for every little thing that you want to do.

[@mdkieran]

For consistency. Some actions indeed may be small, but at least you know where they all are and can easily find them. Also, if you need to enhance their capabilities then you can by introducing private methods and properties. You could also build your actions in such a way that you can process them as background jobs if you need to. There's just a lot more potential with them than standard functions.

[@victoranski1]

My friend Actions are good way to do DRY But using mocks when you have a db connection is just asking for future refactoring of your tests Please learn how to do black box testing

[@mahmoud-bakheet]

You are the other Jeffrey either 😂

[@arash5094]

Please integrate in mongodb to next version of laravel you think it's time don't you