How to treat Filament resource logic in relation to the rest of my laravel app architecture?
I am not sure how to ask this, but I hope the essense of my question makes sense.
I am wondering how I should interpret Filament resource files compared with the rest of the laravel architecture.
For example if I have a textinput column in a resource table, changing this would trigger a eloquent model update. Then I could technically use the model observer to add logic when the model is updated.
But I prefer to use actions, as I usually send requests to a controller, which then triggers an action, which uses methods from a Service class that contains the business logic, and dispatch an event from the action, etc..
So for example if I have an action button in a filament resource table, that updates an attribute of a record, I could also trigger methods from a Service or trigger an app/Action/UpdateXyz class.
So should I treat whatever happens in Filament as a controller, or where should I place whatever happens in filament in relation to the rest of my laravel app?
2 Replies
You can add it to ->after() on the actions? or just use a standard observer like you always have since the model is still being updated..
I want to use observers as little as possible, as I feel like it can make the app architecture messy very quickly. I ended up using getting business logic from services and trigger actions in app/Action/ from filament resource actions and field state changes