Open CWAscend opened 1 month ago
+1
Couldn't this also be its own package?
Furthermore, could you please add tests?
Couldn't this also be its own package?
@Wulfheart happy to wrap this up into it's own package if the community believes it'll be useful. Where else can you see this being useful away from the Laravel Actions package?
Furthermore, could you please add tests?
Of course, will add some test coverage for this 👍
@Wulfheart @lorisleiva
I've added tests as requested, and have also added nesting/shallow nesting support.
For example
Route::actions('photos.comments');
will generate:
I've also added the ability (and test coverage) to allow developers to override the name of the Action class that is resolved in the routes, by using. For example, adding this to your RouteServiceProvider
use Illuminate\Support\Str;
use Lorisleiva\Actions\Routing\ActionResourceRegistrar;
ActionResourceRegistrar::resolveActionClassNameUsing(
function ($resource, $method): ?string {
return ucfirst($method)
.ucfirst(Str::camel(str_replace('.', '-', $resource)))
.'Action';
}
);
If we return null
from the above, it will fall back to whatever the default is defined as in this package.
@Wulfheart @lorisleiva any thoughts?
I don't mind adding this. I think it's well tested and could benefit some people but I find the name of the macro confusing.
We already have a way of registering routes within actions by doing Actions::registerRoutes()
. Adding Routes::actions()
to the API may confuse people as the distinction between the two isn't clear.
I'd rather have a slightly more lengthy macro name that better describes the operation such as Routes::resourceAsActions()
, Routes::actionsResource()
or even Actions::registerResourceRoutes()
.
I don't mind adding this. I think it's well tested and could benefit some people but I find the name of the macro confusing.
We already have a way of registering routes within actions by doing
Actions::registerRoutes()
. AddingRoutes::actions()
to the API may confuse people as the distinction between the two isn't clear.I'd rather have a slightly more lengthy macro name that better describes the operation such as
Routes::resourceAsActions()
,Routes::actionsResource()
or evenActions::registerResourceRoutes()
.
Route::resourceActions()
makes sense, I much prefer that to be fair! How do you envisage Actions::registerResourceRoutes()
working? I'm happy to try and implement something here to keep the resource registration service provider driven, although I'm not sure if there is a clean way of doing it.
How would we define the individual namespaces if Actions are not in the app/Actions dir, how could we specify
->only('index', 'store')
as an example, and how can we tackle nesting/shallow nesting?
I personally think we should keep resourceful actions as solely defined in route files for the above reasons
I absolutely love this package, but the only thing I don't like is having to declare all of my Action routes individually, and losing the ability to define resourceful routes.
This PR attempts to achieve this, by leveraging the
Route::resource()
function and swaping out theController@action
for the action class.Example usage:
The benefit of this is that it will force developers to have consistent routing AND consistent Action naming. Now the names of these are up for grabs, but I've gone for:
GetAddresses
- this replacesController@index
ShowCreateAddress
- this replacesController@create
ShowAddress
- this replacesController@show
ShowEditAddress
- this replacesController@edit
CreateAddress
- this replacesController@store
UpdateAddress
- this replacesController@update
DeleteAddress
- this replacesController@destroy
Example - the following two route declarations:
produces the following routes:
As I mentioned above, if the Action is under a different namespace, we can specify that:
which produces: