laravel-data v2

[rubenvanassche]

So it is time to start thinking about what version 2 of spatie/laravel-data will look like. This is what's in the pipeline at the moment:

Will certainly be added:

• Add support for Undefined properties (add sometimes rule & undefined concept #79)
• Wrap DataCollections in a data key to be more like JSON API (Wrap collections in a key #43) -> we should revisit this PR, actually only the toResponse method of data objects and collections should wrap the thing in a data key
• Allow custom mapping of property names using MapFrom and MapTo when creating or transforming a data object (@phh is working on this)
• Allow injection of route attributes into the data object (@aidan-casey is working on this)
• Respect password validation defaults ([V2] Respect Password Defaults #81)
• Remove check for authorized method DataFromSomethingResolver line 67
• Allow DataCollection::from($items) to also cast already existing data objects into the correct data objects of the collection
• Add generic types to DataCollection
• Split Lazy in subclasses like DefaultLazy, ConditionLazy, RelationAwareLazy
• A complete rewrite of DataClass and DataProperty with support for caching
• Allow PHP 8.1 enums without an explicit cast
• Add PropertyNameMapper classes that would allow to map the names of all properties within a class when creating or transforming a data object. An example of such a mapper would be SnakeToCamelCasePropertyNameMapper. We could use these classes together with the MapFrom and MapTo attributes.
• Simplifying the custom creation method code, at the moment this code is quite complex and you can only pass one parameter in a from method. We could just loop over all from* methods, check if the object can be constructed and if not catch the exception and try the next from* method.
• Add a new unified pipeline for resolving Data objects
• Splitting DataCollection into DataCollection and PaginatedDataCollection, this makes working with data collections a lot more clear. Also paginated data collections can only be used on the top level so this would make a lot of code a bit more readable.
• Support for errorBag, stopOnFirstFailure and redirect for validation.
• Add a $context array to a cast to provide values arround the casted property (Dynamic casting based on passed data #102)
• Allow only and except methods on data objects

If you have any ideas, please let them know down bellow!

[aidan-casey]

To some degree we are getting into normalizing data when we talk about the creation method code and the unified pipeline for resolving Data objects. I am wondering if some sort of normalizer that can be tapped into might be worth adding.

For example:

Normalization provider Interface:

interface NormalizerInterface
{
    public function supports(mixed $value): bool;

    public function normalize(mixed $value): array;
}

Used like so:

// Register some default providers.
Normalizer::register(new RequestNormalizer);
Normalizer::register(new ModelNormalizer);

// The data is normalized and then passed through the pipeline.
// If no provider supports the type, an exception is thrown.
class Resolver
{
    public static function from(mixed $from)
    {
        return new static(
            Normalizer::normalize($from)
        );
    }

    public function __construct(array $data)
    {}
}

[iamrgroot]

I would like an option to easily convert one DataCollection or Array of DataObjects to another DataCollection.

Right now the ensureAllItemsAreData function only checks if it is a data class, not which one. See:

    protected function ensureAllItemsAreData()
    {
        $closure = fn ($item) => $item instanceof Data ? $item : $this->dataClass::from($item);

        $this->items = $this->isPaginated()
            ? $this->items->through($closure)
            : array_map($closure, $this->items);
    }

The problem is de following: when you put a DataCollection<BarData> in the collection function of FooData, the result is a
DataCollection<FooData> but the elements are actually BarData data classes:

// @var DataCollection<BarData> $barDataCollectiom
FooData::collection($barDataCollection);
// or
FooData::collection($barDataCollection->all());

I would like this to be extended to check the actual data class. Maybe the function can be changed to something like:

    protected function ensureAllItemsAreData()
    {
        $closure = fn ($item) => $item instanceof Data && $this->dataClass === $item::class ? $item : $this->dataClass::from($item);

        $this->items = $this->isPaginated()
            ? $this->items->through($closure)
            : array_map($closure, $this->items);
    }

Maybe this could be done optionally or configurable or with a new function. I think it would be nice if this conversion would be done automatically. Right now it seems I have to use a helper function in my own Data class to make sure the Data classes are converted correctly.

use Spatie\LaravelData\Data as LaravelData;
use Spatie\LaravelData\DataCollection;

abstract class Data extends LaravelData
{
    /**
     * @param DataCollection<Data>|array<int|mixed, Data> $collection
     *
     * @return DataCollection<static>
     */
    public static function dataCollection(DataCollection|array $collection): DataCollection
    {
        return static::collection(array_map(fn (Data $item) => static::from($item), [...$collection]));
    }
}

[rubenvanassche]

Good point, I've added this feature to the list! In my opinion this should be default behavior.

[suyar]

Is there any release plans for V2, and is it compatible with V1?

[rubenvanassche]

It will be mostly compatible with V1, an exact release date I can't provide you. Hope as soon as possible! You can follow along on the v2 branch.

[francoism90]

@rubenvanassche I know you have this planned for V2, however would you consider adding things to V1? 'Allow only and except methods on data objects' - Could this be added to V1? If so, I'm also open to provide a PR. :)

[rubenvanassche]

Hi @francoism90, I think v2 it is just a few weeks away. The only and except methods are already added to v2 so keeping 2 versions of this code is a bit too much at the moment.

[andreintm]

hey, any updates on that? When that will be released?

[freekmurze]

Behind the scenes, we've been busy with client work. We need some more time to finish this package. Follow Ruben, me, or Spatie on Twitter to see when it gets released.

[ralphjsmit]

Thanks for this package and excited to see the V2 being in the works! I have two feature requests that I think will make the package even better.

Easier custom collections

I'm a great fan of custom collections. Currently I implement them like this:

class Collection extends DataCollection
{
    // Custom methods
}

class RichText extends Data 
{
    public static function collection(Paginator|Enumerable|array|AbstractCursorPaginator|DataCollection|AbstractPaginator $items): DataCollection
    {
        return new Collection(static::class, $items);
    }
}

Is it possible to add easier support for them, without having to overwrite the "collection" method? For example like this:

class RichText extends Data
{
    protected static string $collection = CustomCollectionClass::class;
}

Implementation would be fairly easy:

class Data
{
    protected static string $collection = DataCollection::class;

    public static getCollection(): string 
    {
        return static::$collection;
    }

    public static function collection(Paginator|Enumerable|array|AbstractCursorPaginator|DataCollection|AbstractPaginator $items): DataCollection
    {
        return new (static::getCollection())(static::class, $items);
    }
}

DataCollection extends Illuminate\Support\Collection

I'm not sure whether this is technically feasible (though I hope so), but it would be great of the DataCollection could extend the Illuminate Collection. The reason I'm asking is that there are quite some methods missing from the DataCollection class, that are present in the Illuminate Collection. For me, this makes the DataCollection class much less usable.

For example: where(), sole(), first(), pipe(), pipeInto(), pipeThrough(), reduce(), each(), map().

If this is not possible, would it be possible to at least implement the where(), first(), sole(), each(), and reduce() methods?

Thank you!

[iamrgroot]

We have created an early implementation of an OpenAPI specification generator that relies on Laravel Routes + Data request and data response objects (using reflection).

Are there others with interest in this? Would this be something that could be integrated in the main package? Or could this be a separate package?

[rubenvanassche]

Hi @iamrgroot,

I think this will be quite a bit of code and I don't want to blow up the package since is already fairly complicated. That being said, I really like the idea so if you would create a separate package, then I would certainly link to it in the docs!

[dmyers]

@iamrgroot Have you released this by chance? I'm interested in using it.

[iamrgroot]

@dmyers I've just made this public: https://github.com/xolvionl/laravel-data-openapi-generator

It has only been used internally, so we haven't published anything to packagist (yet)

[rubenvanassche]

That's really cool! Would it be all right for you if I'm adding this to the docs?

[iamrgroot]

@rubenvanassche sure!

[juse-less]

While prematurely converting to v2, I noticed quite a bit of errors showing up in both Telescope and Ray, while DateTimeInterfaceCast is traversing the list of possible formats.
Would it make more sense to change the call to rescue(), and set the 3rd parameter ($report) to false by default, so it doesn't report every failed attempt to find a format?

I'd also like thank you for this excellent package.
I've cut so much overhead thanks to this package, and v2 is an even more giant leap forward. ❤️

[rubenvanassche]

We've officially released laravel-data v2! 🎉

[suyar]

Great! Thank you for your contributions!

[martio]

Thank you! 👍

[ahoiroman]

Great :-) Thank's a lot! Migration to v2 took me < 5min :-)

[beeyev]

That's great news.
Did you manage to implement MapFrom & MapTo methods?

[juse-less]

@beeyev I believe you're looking for this.
You can also combine them with, say, globally mapping by snake_case, and then overwrite on a property-by-property basis (including from custom names).