Add support for factory states [enhancement]. Closes #452 #686
Conversation
|
Hey there. Looks like you've got some pretty opinionated linting on your local machine. You'll have to fix the linting using the patch provided by StyleCI to get the builds green. |
|
Thank you for all your help @ScopeyNZ |
| @@ -193,6 +193,8 @@ public function show($id) | |||
| If your controller method uses [Eloquent API resources](https://laravel.com/docs/5.8/eloquent-resources), you can use the apiResource annotations to guide the package when generating a sample response. The `@apiResource` tag specifies the name of the resource. Use `@apiResourceCollection` instead if the route returns a list. This works with both regular `JsonResource` objects and `ResourceCollection` objects. | |||
|
|
|||
| The `@apiResourceModel` specifies the Eloquent model to be passed to the resource. The package will attempt to generate an instance of the model for the resource from the Eloquent model factory. If that fails, the package will call `::first()` to retrieve the first model from the database. If that fails, it will create an instance using `new`. | |||
|
|
|||
| The `@apiResourceState` specifies a comma delimited list of states to be passed to the Model Factory. | |||
There was a problem hiding this comment.
Sorry, the description wasn't that great. @apiResourceState is the docbloc that specifies which factory state to use. It's comma delimited so it can be something like
@apiResourceState delinquent,subscribed
and it will apply the ->states(['delinquent', 'subscribed']) to the factory
There was a problem hiding this comment.
I'm talking about what I said in the linked comment...? Why go in this direction instead.
There was a problem hiding this comment.
I went the way I did because it was easier to implement, and also followed the same syntax of every other docbloc where it never uses =
There was a problem hiding this comment.
Nah, I don't want us adding another annotation. It's going to be more overhead dealing with the different annotations that we'll end up with—apiResourceState, transformerState etc. I proposed we go with the state= approach because it's easier to extend. For instance, if we're adding model relations, we can add a with= . It might be more work, but it's better in the long run, so I'd like us to move towards parameterized annotations.
Allowing nunomaduro/collision to use also version 4.0
Update to head
Updating nunomaduro/collision
No description provided.