[Feature Request]: Allow for any attribute to be added to the config of filters

[khwadj]

Overview

As I'm working with NumberFilters (see issue #1999), I realized that the attributes that would be placed on the input are hardcoded in the view for that filter.

A few attributes are allowed in each filter view, and are pulled from the filter's config.

Detailed explanation

Example: NumberFilter

resources/views/components/tools/filters/number.blade.php

     @if($filter->hasConfig('min')) min="{{ $filter->getConfig('min') }}" @endif
     @if($filter->hasConfig('max')) max="{{ $filter->getConfig('max') }}" @endif
     @if($filter->hasConfig('placeholder')) placeholder="{{ $filter->getConfig('placeholder') }}" @endif

This means that the user cannot define other valid attributes for a number input (ex: step, maxlength) without locally overwriting this view. The user cannot define any custom attribute either, from which they would benefit for whatever reason they might have.

Notes

Proposed solution:

Simply iterates on the config item and set every key in it. It's the developer's responsibility to add attributes that make sense.

resources/views/components/tools/filters/number.blade.php

    @foreach($filter->getConfigs() as $attributeName => $attributeValue )
           {{ $attributeName }}="{{ $attributeValue }}"
    @endforeach

In addition, it could be interesting the implement a blacklist of config keys to avoid breaking stuff: id, class, type, wire:key.

Views/Traits/Core/HasConfig.php

trait HasConfig
{
    public array $config = [];
    public array $configblacklist = [
        'class',
        'id',
        'type',
        'wire:key',
    ];

    public function cleanConfig(array $config = []): array
    {
        return array_filter($config, fn($item) => !in_array($item, $this->configblacklist));
    }

    /**
     * @param  array<mixed>  $config
     */
    public function config(array $config = []): Filter
    {
        $this->config = $this->cleanConfig($config);

        return $this;
    }

    ....
}

Finally, it might be worth allowing the user to add custom classes to their input on top of other attributes, but this is arguably another feature.

[lrljoe]

So - custom classes for the input, that's a feature that is in the works, and should be out in a few versions time.

Very good point in terms of allowing a wider range of attributes to be merged in though, and something I'll definitely look at for the next release, with NumberFilter as the first target, as some of the others do have more specific matching built in, so it'd have to be NumberFilter specific to start with.