Why Actions in Laravel 8?

I am surprised that the actions were not combined into one class instead of several. Sort of like the trait that laravel UI has.

Consider reading this post by freek https://freek.dev/1371-refactoring-to-actions

And they even have a package https://github.com/spatie/laravel-queueable-action

@sinnbeck Will do. Thanks!!

@jlrdw that way it is easier to maintain and respect programming principles. Also easier to reuse and to see what app does exactly.

I think that it depend on project that you are working. In case of jetstream that has two frontend, livewire and inertia, actions is being used to share common logic.

In most small-medium project I think that is uncessary abstractions.

MVC is already a solid pattern, where you separated things, also Laravel offer Form Request which allow to share validations.

Most of time I have admin, frontend and maybe API. Validations are shared via Form Request, controllers are slim and most of logic is in Model and sometime in Repository.

For my small-medium project is pretty enough.

For other large project with many developers involved could make sense.

@thewebartisan7 that kind of structure does not make code reusable. But for something like Tailwind Playground I definitely understand why they did everything in route file callbacks.

I agree with MVC point only on ultra-small projects.

that kind of structure does not make code reusable.

I point out that there is nothing to be re-used in most small-medium projects where you have admin, frontend and maybe API. Let's say user models, in admin area you do CRUD for all users, in frontend you allow logged-in user to edit profile. What is re-used is validation, that you can extract in Form Request. Something else can be placed in models, and in case you need to share logic you can create a Repository, or for example upload of avatar, you can create a Service class, Support or Helper, call it how you like. Same can be applied to any other models.

Taylor also said in video that this actions was created to handle multiple frontend, and in most project you have only 1 frontend. So is unecessary complexity added if you have just one frontend.

Front end isn't my main concern, having full control over authentication is. I think the trait that the UI uses and the UI scaffolded Auth gives the developer more control.

As I stated in another post and just example:

There are a large insurance chains , such as Humana that has major login sections Physicians, Patients, and government entities all separate of course.

Fortify does not seem to be geared up for such an Enterprise development.

It takes code from the non-changeable vendor directory and puts it in your app where you can vary the functionality - such as when creating a user.

Personally, I preferred the previous method of creating controllers which then pulled traits from vendor which you could override.

@snapey did you see the screencast From Taylor where he said UI will be maintained in future versions?

@thewebartisan7

I point out that there is nothing to be re-used in most small-medium projects where you have admin, frontend and maybe API.

Haven't worked on a project that had absolutely no need for reusability.

Projects that have admin CRUD is already not a small project in my mind. And if API is added to the mix then that is truly not a small-mid project.

What is re-used is validation, that you can extract in Form Request.

I always create Request classes no matter what.

So is unecessary complexity added if you have just one frontend.

You say unnecessary complexity, I say required simplification. If you want to quote people then Jeffrey Way says that "juniors are reluctant to create new classes and separate concerns". Uncle Bob says that "use cases should dominate the app and not patterns like MVC/folder structure".

Point is that all apps tend to get bigger. So why postpone necessary?

Haven't worked on a project that had absolutely no need for reusability.

Of course we re-use many codes across projects and inside projects, from frontend to backend.

But there is not need in all projects to split code in multiple class, interfaces, etc. in all projects that you are working on, that is my point. If for you Fortify/Jetstream is semplification compared to Laravel UI then we have different understanding of semplification.

Projects that have admin CRUD is already not a small project in my mind. And if API is added to the mix then that is truly not a small-mid project.

Admin that do CRUD can be very easy when you do that with standard MVC logic, even if you have dozens of models. For you maybe use a CRUD like Nova or Backpack maybe is a semplification following your logic with Fortify/Jetstream, but for me is complication. You do 80% in 20% and the rest missing 20% in 80%, the famous rule. If you think that CRUD is something complicated, then you can learn from Spatie what means beyond the CRUD: https://laravel-beyond-crud.com/

I have my own CRUD generator with a few click I build Edit, Update, Softdelete, Restore, Mass Actions, and much more with a single line of code or via browser UI, for admin and API, with Searching, Filtering, Autocomplete, etc. It generate files such as controllers, models, views, request, policies, etc. I am freelancer and I work on small-medium project mostly alone or with a small team of other freelancer, and I know very well most of patterns, and I try many of them. In the end you lose time thinking how to create the perfect abstraction, and come to a complexity that it's more hard to manage than re-create something similar.

I always create Request classes no matter what.

You don't use request classes with Foritfy, and I thnk you don't use in login. I also think that is unecessary to use in all forms, there are small case where you don't need them. There is no generic rule for everything.

@jlrdw

did you see the screencast From Taylor where he said UI will be maintained in future versions?

Yes, but I've not used bootstrap for 2 years. Although there is a TALL stack preset for Laravel/UI I prefer Jetstream.

@thewebartisan7 sorry but your logic does not make sense to me. First you say that something that is more complex in your mind is simpler for me, and then you say that CRUD is complicated for me.

Respecting common patterns and principles is just a common sense since code will be understandable, expressive, encapsulated and polymorphic. All that makes code easier to change compared to having 1000 lines long controllers.

I do not waste time thinking about perfect abstractions. TDD is the star I follow and for years I haven't added unnecessary line of code. Everything is mostly a muscle memory at this point.

But there is not need in all projects to split code in multiple class, interfaces, etc.

If you do not do it in the beginning then you will not do it when it is needed cause there is a huge chance that you will miss to spot that point in time. I work on enterprise apps for 10 years now, and architecture is essential for developer happiness.

I was just trying to have a quality discussion, but I guess that is not possible since we have different standards.

Thanks, guys for all the responses and discussion! It was awesome seeing this kind of discussion in real-time! I also think I got a good understanding of the differences.

@bugsysha I absolutely agree. And I have seen projects where that exact thing happened. Controllers or models that have waaay to much logic and is bloated. Just because it wasn't planned properly earlier in the project.

First you say that something that is more complex in your mind is simpler for me, and then you say that CRUD is complicated for me.

You are taking my words out of context and making allusions about what I wanted to say. For you is simpler Fortify/Jetstream vs Laravel UI is one thing. For you CRUD is something not "small", for me is something easy to do with 100 lines of code in controller, removing comments. This are two separated things. I then also point that (maybe) for you CRUD is complicated when working with package like Nova or Backpack. It was an assumption. There is not correlation, apart point out that such abstraction can only make things more complicated. Because Nova and Backpack has their use case in large project, and also Fortify/Jetstream has their use case. I am saying that in most small-medium project, such package like Nova/Backpack/Fortify/Jetstream are unecessary.

To explain a bit more what I am saying regarding CRUD being simple see this gist:

https://gist.github.com/thewebartisan7/99c9882dfaad0def42fd61e16ec5c19b

This is a generated controller with CRUD in admin for a dummy model. Removing comments and sorting/filtering/searching of query builder package, each methods has 2-3 lines of code, so maybe there are less than 100 lines of code.

Considering you have also API, then controllers will looks like: https://gist.github.com/thewebartisan7/1e1302e851088e9830b8b4ea8869c950

Also this very slim.

For reusable code logic I use packages which I can share even between project, but make reusable a few lines of code make things only complicated when you need to put some conditions.

Everything is mostly a muscle memory at this point.

This happen only when you create a logic like Fortify/Jetstream or Nova/Backpack. You don't need to use memory to understand similar small part of code such as above controllers or such as Laravel UI controllers. I never need to remember how to do something with Laravel UI, because it's there easy to find once you open controllers. While with Fortify, after working a few weeks ago on it, I already forgot how to do even simple task on it. Such abstractions is not bad, I am not saying that. It has their use case. But in some project it's not good at all. I guess if you are using the same logic for all your code like Fortify/Jetstream by adding interfaces, and features enable/disable for each features you add in code. I don't think so.

I was just trying to have a quality discussion, but I guess that is not possible since we have different standards.

There is not standards in code, the right answer is depend on project you are working on.

I would just conclude with one questions: what is more easy exctract logic of Laravel UI in actions if you need them, or make Fortify/Jetstream like Laravel UI? First thing is possible, second is not. So as starter point for an auth, Laravel UI is winner. You can do with it the same things if you need.

No hard feeling for me, I think much more was said already in web, especially in reddit about this debat, and I see two different views on this. I personally agree with above, it depend.

Glad that OP has help understand the direction where he need to go.

@thewebartisan7 sorry since English is not my strong point I'm having really hard time understanding you. What you are saying is so confusing to me cause everything sounds inconsistent. You say one thing then the other.

@sinnbeck exactly. Who ever left things for later never did them. And then new members join the team and just keep adding the code in the same fashion as they see in other places. Then everybody starts adding if statements cause you can not justify to the owners why such a small thing takes forever to add. Basically that is the end of that project. Before you know it you have an app without any architecture and encapsulation that has 1000 queries per page and everything is too tangled. It is slow and almost no possibility to figure out why bugs are happening and fix them without introducing new bugs. You start loosing customers and the thing that should take few hours to add with correct architecture now takes days while it breaks other things that should be unrelated.

Thanks for listening 🤪

I think that I was clear in my arguments. He who has ears to hear, let him hear. Bless

@thewebartisan7 super clear to yourself. I would never say that I was clear if the person I’m talking to did not understand me. All best.

I just notice that you seem not interested to understand. When I don't understand something, I ask specific things that I don't understand. When you reply "What you are saying is so confusing to me cause everything sounds inconsistent. You say one thing then the other." that doesn't say too much what you don't understand. So is hard for me to try explain everything again.

Let me try explain with an example. Not sure if you know Spatie package https://github.com/spatie/laravel-view-models which offer the so called view model pattern. Even if this may be good in large project, is unecessary for small project.

From Spatie blog about this view model pattern, quote:

"Now I know that this isn't a problem in small projects. When you're the only developer and have 20 controllers and maybe 20 view composers, it'll all fit in your head.

But what about the kind of projects we're writing about in this series? When you're working with several developers, in a codebase that counts thousands upon thousands lines of code, it won't all fit in your head anymore - certainly not on that scale."

I agree with this, and this resume of my points above, I think very clearly. Even a good pattern is not always required in all project.

@thewebartisan7 I am curious about the view model package. On the symfony codebases I am in working in for (BIG FINANCIAL) contract we use view models all the time, but in Laravel only up to recently they haven't been defacto, and are now introduced as API Resources.

From your experience of View Models can you see any difference between those and API Resources or are they an equivalence.

Also in agreement with your Spatie quote.

I think its essential to know the tools that are available even if you don't end up using them now. Even more important if you are growing your codebase or have an open source project.

@automica You can combine API Resource with view model, because you can also return the view model itself as JSON data, by implementing Responsable.

Example:

class PostViewModel
{
    // …
    
    public function values(): array
    {
        return PostResource::make(
            $this->post ?? new Post()
        )->resolve();
    }
}

…but that would be silly.

@martinbean You can blaim Spatie, because this is their solutions, not mine.

Quote spatie:

"You might see a similarity between view models and Laravel resources. Remember that resources map one-to-one on a model, whereas view models may provide whatever data they want.

In our projects, we're actually using resources and view models combined:"

class PostViewModel
{
    // …
    
    public function values(): array
    {
        return PostResource::make(
            $this->post ?? new Post()
        )->resolve();
    }
}

@thewebartisan7 you've noticed wrong. I've asked nicely but I've also tried to cut it short and avoid any conflict since as I said we have different standards. Who knows, maybe we do agree on things but that is hard to explain without code samples and in threads where I try to be as concise as possible. It's just that the way you write is confusing to me or maybe that is caused by my interpretation of what you are trying to say.

All best and may the Schwartz be with you.

I've asked nicely but I've also tried to cut it short and avoid any conflict since as I said we have different standards.

Actually, you have not asked nothing :)

Quoting your message:

"@thewebartisan7 sorry since English is not my strong point I'm having really hard time understanding you. What you are saying is so confusing to me cause everything sounds inconsistent. You say one thing then the other."

No questions here :)

It's just that the way you write is confusing to me or maybe that is caused by my interpretation of what you are trying to say.

I agree that is a mix of two. English is not my primary language, but I think you are also making your own interpretation. Considering the belief that most of communication is body language, part is the tone of voice, and very small part is the actual words spoken, it's easy to get misunderstand via written communication such as this. It is said that about 10% is verbal, so we missed 90% of the communication. But try reading again, and see if you agree almost with Spatie quote. You can't disagre with that.

All best and may the Schwartz be with you.

It took me a while to understand where this sentence came from. But then I remembered... Spaceballs :) I like more the origin of this phrase, and is not "May the force be with you", but the original is "May the Lord be with you."

Bless

Point is that all apps tend to get bigger. So why postpone necessary?

@thewebartisan7 I did ask, but you went on to answer what you though was important, but it was not actually a question. I knew it would lead the conversation on to a hard path and that is the reason why I tried to stop it.

Cmon, can we at least agree that Spaceballs are far better than Star Wars? 🤣 I'm kidding.

No hard feelings. And may the science and logic be with you (South Park).