Multi Use Action Strategy
I dont know about you, but I create a lot of custom Actions, mainly because I am not using the panel builder at the moment, so with standalone tables and forms, I have to create an action for everything. There are many times where I have an action that I can use in multiple situations, such as tables, forms, infolists, and just standalone actions. Unfortunately as you all know, the action has to match the type that its being used in. Should I create a class for each type and then simply use a trait for shared logic? 95% of the logic is the same it seems. Just trying to reduce any duplication.
6 Replies
Obviously it works a bit differently when doing a normal standalone Action though as it wouldn't have access to $record and that would have to be set
ugh, spent at least 20 minutes trying to figure out why my regular action wasnt firing and it was simply missing
parent::setUp(); on setUp() in the custom action
So a trait does work, but i am finding out that a form action cant be passed a ->record() like you can with a regular action. My particular issue is that the action is on a relationship of that record and of course its trying to use the parent record. Must be a way to set it, but not having any luckI think I'd use some kind of service class (just a simple, plain PHP class) to encapsulate the logic instead of a trait. A bit easier to test in isolation if that's desirable.
My particular issue is that the action is on a relationship of that record and of course its trying to use the parent record.Can you share an example to illustrate this issue?
I honestly haven’t done much with service classes, I will look into that. I guess it now boils down to the ability to pass a record to any action. Seems I can do that with a regular action with ->record(), but not a form action.
I guess the problem passing a record to a form action is that, at least I think. It already has the record so it shouldn’t be necessary to pass it in.
I think once teleporting modals becomes possible we wouldn’t need to have separate form / table / page actions, since they could all be teleported to the same singular modal container.
oh man that would be amazing as they do make things a pain
well not necessary is more an assumption, but a form action now isnt just for submitting a form
Always been my biggest gripe with filament, but understandable why it’s the way it is, is that modals can’t be called from anywhere like notifications can.
Also not sure of the best way to make it happen.
You’re not wrong, I guess it’s more that it has access to the state than the record, since a record wouldn’t exist on create.