[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.

[lrljoe]

So having looked at the approach for this, blacklisting at this stage on a more global level, probably isn't viable.

However, for NumberFilter, I'm doing some testing:

public function getConfigsForBlade()
{
  return collect($this->getConfigs())->except(['wire:key', 'wire:model', 'wire:model.live', 'wire:model.blur', 'id', 'type', 'class', 'value']);
}

Now for a release, I would need to ensure that any of the alternative filter behaviours etc are also ignored, such as where debounce etc are used.

Then in the "components.tools.filters.number.blade.php"

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

Which so far seems to be working, I will just need to do some further testing, and ensure that other approaches aren't impacted

[lrljoe]

Self reminder to review this again

[lrljoe]

So before we can make this a global feature, we need to:

• Identify (and document) any core attributes that are utilised within the core package

Otherwise, yes, absolutely, and I've added this to the to-do list.

[lrljoe]

So it's looking possible that I'll add in a
setFilterInputAttributes for filters where its possible to support this.

Rather than using the config approach, and then slowly migrate (in a non breaking way) any existing config options that are an input attribute, into this.
Then config will be purely for configuring, rather than attributes.

This should allow the same approach for the majority of the filters, as config for NumberRange filter for example actually does config related things.

[lrljoe]

Just a note that this is still in the works!

[lrljoe]

This is fully in-progress, and should be in one of the next releases

[lrljoe]

This is still progressing well, but I'm aware that I still need to write the tests and docs.

It is likely that I'll release this in several stages, covering a chunk of filter types in each release, to try and get the feature out for at least some filters sooner rather than later.

[lrljoe]

@khwadj - several of the filters now support this behaviour in the development branch

Complete

• DateFilter
• DateTimeFilter
• MultiSelectDropdownFilter
• MultiSelectFilter
• NumberFilter
• TextFilter
• SelectFilter

In Progress
N/A

Special Note

• BooleanFilter <- as this is Tailwind only, and depends heavily on CSS to present, I'll be exposing some specific attributes to allow customising

Excluded

• DateRangeFilter
  Due to how this is implemented, this will be excluded for the time being

• LivewireComponentFilter/LivewireComponentArrayFilter
  As the display is wholly on the end-user, these are excluded

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.