Ability to disable wrapping on a Resource per resource

[tombanksme]

I'm using Inertia + Resources to load data into a Vue component like this:

public function show(Profile $profile): Response
{
    return Inertia::render("profiles/show", [
        "profile" => new ProfileResource($profile)
    ]);
}

Due to the wrapping, in my Vue component profile data is accessible via props.profile.data. To workaround this I've created a Resource which all of my resources extend from (like we do with the controllers).

new ProfileResource($profile, wrap: false);

If there's any interest in having this functionality in the main codebase let me know and I'll get a pull request created. I'm also thinking about creating a HasResource trait (similar to the HasFactory trait) which will allow me to do:

public function show(Profile $profile): Response
{
    return Inertia::render("profiles/show", [
        "profile" => $profile->toResource()
    ]);
}

To quickly wrap the profile in the correct resource using the model name and namespace. Let me know if there's any interest in either of these ideas 😄

[henzeb]

Are you talking about https://laravel.com/docs/9.x/eloquent-resources#data-wrapping?

It can already turned off per resource, although your description explains as if you want it to be turned off globally.

[tombanksme]

So I want to be able to turn data wrapping off for only this resource I'm about to construct.

Currently I can turn it off for all of the ProfileResource or none of them.

[henzeb]

Ah. On instance-level.

[MannikJ]

This problem just forced painfully me to refresh my knowledge about phpunit and how static variables are used during tests.

What happened to me was that I was calling withoutWrapping() in my custom base resource and base resource collection classes. It normally worked as expected, because in most cases its fine and your API is supposed to act in a uniform way (wrapping yes or no, but not a mixture). But there can also be cases where you want or need to have this mixture - and this is where this design has the potential to produce a lot of issues.
I added a new endpoint where I wanted the JSON responses to be data-wrapped. The API test for this route worked fine when I ran it individually, but failed when running together with certain tests.
It took quite some time to realize what was happening here: All tests running before which somehow caused the call to withoutWrapping() also caused the new route to lose its data wrapping, because the underlying property was defined as static and therefor available across all tests.

I would consider this a design flaw to have the $wrap property defined as a static variable. Especially in a framework's base class which is designed to be used all over the place. I would like to start a discussion how we can improve this without breaking too much. At least there should be a warning that calling this function might lead to unexpected issues especially in the tests.

Another example where this problem would lead to conflicts is, if an installed package also uses the default wrap property of the base class.

For others who might encounter a similar problem, there are as far as I know only two things you can do right now to work around the problem:

1. Make sure that in each inherited class itself the property has the desired value by setting it explicitly again
   1.1 Not call withoutWrapping() at all, or at least make sure that each inherited resource class which modifies the $wrap property, redefines its own version of it to decouple the modification from the version of global base class. If you redefine the property, it will reside in a different location in memory.
2. Run your tests with --process-isolation - which is not the best idea, because it is damn slow.