Route::formation refactor

[dillingham]

Route::formation(PostFormation::class)
    ->resource('posts')
    ->pivot();

Route::formation(PostFormation::class)
    ->resource('posts')
    ->import();

Route::formation(PostFormation::class)
    ->resource('posts')
    ->pivot()
    ->import();

The current implementation sets a flag of this->pivot = true

But if we could refactor that method to somehow register the routes

And ->resource to continue only register the default routes when not pivot or nested / parent

Then we could avoid having multiple code blocks to add multiple features per resource

In this example, pivot() and import() both are formation features that add own routes

---

Im also wondering if this would be more clear and preferred by developers

Route::formation(PostFormation::class)
    ->addResourceRoutes()
    ->addPivotRoutes()
    ->addImportRoutes();

and then use ->resource('posts') to override a resource guess (todo) based on formation

Route::formation(PostFormation::class)

would be the same as the following but not needed because of being the default behavior

Route::formation(PostFormation::class)
    ->resource('posts')
    ->addResourceRoutes()

But maybe only needed if they add multiple routes, if so.. resource routes are not default added

---

Thought: would be cool if you could click through the addResourceRoutes and easily see the routes created

Might help some people debug or feel like less magic is happening behind the scenes

Maybe each add{type}Routes method appends an endpoints array?

---

Maybe instead of ->resource() we follow the same convention as filters and fields

Route::formation(PostFormation::class);

Route::formation(PostFormation::class, 'posts');

Route::formation(PostFormation::class, 'author.posts');

Route::formation(PostFormation::class, 'author.posts')->asPivot();