How would you extend the EnumarableMethods trait?

[bjorntheart]

I have a need for a second(), much like the first(), method inside EnumerableMethods.php, but I realise it's very specific to my needs and therefore don't want to create a PR for it.

Is there a way to extend or inject a method into every instance of a DataCollection so that I can call into that second() method on it?

I have a working example of getting to the second item using where():

/**
 * Calculate monthly premium.
 *
 * @return float
 */
private function calculateMonthlyPremium(): float
{
    $installments = [];
    foreach ($this->collection as $item) {
        /** @var DataQuote $item */
        /** @var \Spatie\LaravelData\DataCollection $item->installments */
        $installments[] = $item->installments->where('installmentNo', '===', 2)->first()->amount->value;
    }

    return (float) collect($installments)->sum();
}

Ideally I would like to add:

public function second(callable|null $callback = null, $default = null)
{
    return $this->items->skip(1)->first($callback, $default);
}

/**
 * Calculate monthly premium.
 *
 * @return float
 */
private function calculateMonthlyPremium(): float
{
    $installments = [];
    foreach ($this->collection as $item) {
        /** @var DataQuote $item */
        /** @var \Spatie\LaravelData\DataCollection $item->installments */
        $installments[] = $item->installments->second()->amount->value;
    }

    return (float) collect($installments)->sum();
}

[rubenvanassche]

You can create a custom data collection and use it within all your data classes by creating an abstract data class from which you extend. In that custom collection you could add such a method.

[bjorntheart]

I'm pretty sure I misinterpreted your reply, but here's what I tried.

1. Created a custom use App\DataObjects\DataCollection that extends \Spatie\LaravelData\DataCollection

<?php

declare(strict_types=1);

namespace App\DataObjects;

use Spatie\LaravelData\DataCollection as LaravelDataDataCollection;

class DataCollection extends LaravelDataDataCollection
{
   public function second(callable|null $callback = null, $default = null)
   {
       return $this->items->skip(1)->first($callback, $default);
   }
}

2. I then use it in one of my data classes QuoteData instead of \Spatie\LaravelData\DataCollection

<?php

declare(strict_types=1);

namespace App\Quote\DataObjects;

use App\DataObjects\DataCollection;
// use Spatie\LaravelData\DataCollection;
use App\DataObjects\Premium;
use Spatie\LaravelData\Data;
use App\DataObjects\Enums\Status;
use App\ABC\Enums\MarketingSource;
use App\ABC\Enums\PaymentFrequency;
use Illuminate\Support\Traits\Macroable;
use Spatie\LaravelData\Attributes\MapInputName;
use Spatie\LaravelData\Attributes\DataCollectionOf;
use Spatie\LaravelData\Attributes\Validation\DateFormat;

class QuoteData extends Data
{
    public function __construct(
        public string $brand,
        #[MapInputName('brand_name')]
        public string $brandName,
        public string $coverCode,
        #[MapInputName('coverCode_name')]
        public string $coverCodeName,
        public string $referenceNumber,
        public string $policyNumber,
        public string $policyType,
        #[MapInputName('policyType_name')]
        public string $policyTypeName,
        public string $currency,
        #[MapInputName('currency_name')]
        public string $currencyName,
        public Status $status,
        #[DateFormat('Y-m-d')]
        public string $paymentStartDate,
        public string $policyStartDate,
        public string $policyEndDate,
        public string $policyCreateDate,
        public string $policyFirstStartDate,
        #[DataCollectionOf(Promotion::class)]
        public ?DataCollection $promotions,
        public Premium $collectionCumulativeAnnual,
        #[DataCollectionOf(Installment::class)]
        public DataCollection $installments,
        public PaymentFrequency $paymentFrequency,
        public MarketingSource $marketingSource,
        public int $numberOfClaims,
        public bool $isQuote,
        public string $bundleID,
    ) {
    }
}

Which then produces the following error

"App\Quote\DataObjects\QuoteData::__construct(): Argument #19 ($installments) must be of type 
App\DataObjects\DataCollection, Spatie\LaravelData\DataCollection given, called in 
{REDACTED}/site-livewire/vendor/spatie/laravel-data/src/Resolvers/DataFromArrayResolver.php on line 60"

[bjorntheart]

Any ideas @rubenvanassche ?

[rubenvanassche]

Mhhh, somehow the collect method of your data object isn't using the custom collection and uses the default package data collection.

I can't really tell why this is the case, our tests seems to work:

it('can return a custom data collection when collecting data nested', function () {
    class TestCustomDataCollectionToBeCreatedFromNestedClass extends Data
    {
        protected static string $collectionClass = CustomDataCollection::class;

        public function __construct(public string $string)
        {
        }
    }

    $class = new class extends Data {
        #[DataCollectionOf(\TestCustomDataCollectionToBeCreatedFromNestedClass::class)]
        public CustomDataCollection $collection;
    };

    $data = $class::from([
        'collection' => [
            ['string' => 'A'],
            ['string' => 'B'],
        ],
    ]);

    expect($data->collection)->toBeInstanceOf(CustomDataCollection::class);
});

Did you set the $collectionClass property on the data object?

[MannikJ]

Is there any good reason why the DataCollection does not inherit from Laravel's base collection (Illuminate\Support\Collection)?
I get, that often composition over inheritance is a good idea, but in this case you would really benefit from the additional features of the laravel collection.
I've already fallen into the trap thinking that I can just use the DataCollection like a normal Collection and would be really if I actually could. However, I already implemented the suggested workaround and typed-hinted my own DataCollection with additional features.

[rubenvanassche]

Because collection is maintained by Laravel, they can basically add methods which will break our implementation. For example we have another definition for transform() than the Laravel collection. The plan is to fase out DataCollections in favor of Collections in v4, but that's still a lot of work.

[MannikJ]

I get that, but my weighing would still be in favor of the Laravel Collection. I mean, this is a Laravel package so it's quite tightly coupled anyway and the risk that a change in the framework breaks a feature of this package is always present. It might require some more effort ensuring that functionality is still working with each release, but it also comes with the benefit that you don't have to maintain the mirroring/passthrough of the Collection interface etc.
Collections are one of the most important parts of the framework and I guess its not only me who would assume that the collection you're dealing with is the framework's standard collection.
That being said, it's good to hear that you are going into this direction anyway which makes my argumentation pointless ;)