Adds ability to add filter of type date and pass optionally min& max options.

Here is example code:

public function filters(): array
    {
        return [
            'fromDate' => Filter::make('From Date')
                ->date([
                    'max' => now()->format('Y-m-d')
                ]),
            'toDate' => Filter::make('To Date')
                ->date([
                    'min' => isset($this->filters['fromDate']) && $this->filters['fromDate'] ? $this->filters['fromDate']:'',
                    'max' => now()->format('Y-m-d')
                ])
        ];
    }

Example Output screenshot:

I wonder if it's possible for you @rappasoft to create a new repository called for example livewire-tables-docs which would contain all markdown files currently presented in Wiki? Or maybe even put them into new docs folder, of this repository?

I don't think you alone can handle managing docs. And Wiki cannot be changed by anyone else this way. For example if docs were open to edit for everyone there is some code with bad practice that might be updated to look better and less confusing for new users, some typos etc.

Also this change might give some space to publish docs on some website with better UI and more complex search (good example is Laravel, Jetstream and other docs).

Thanks for thinking this through.

This feature uniquely identifies each table for column selections stored in the session. It also allows for columns selections to be put into the query string, so that selections can be bookmarked.

The tldr; is that we now have a fingerprinting method that uses static::class to generate a key, or slug for each component, to be used as an alias for $tableName in the session and query string arrays, which is always the same for the same component, and always different for another.

    /**
     * returns a unique id for the table, used as an alias to identify one table from another session and query string to prevent conflicts
     */
    public function dataTableFingerprint(): string
    {
        $className = str_split(static::class);
        $crc32 = sprintf('%u', crc32(serialize($className)));

        return base_convert($crc32, 10, 36);
    }

    /**
     * Set the custom query string array for this specific table
     *
     * @return array|\null[][]
     */
    public function queryString(): array
    {
        if ($this->queryStringIsEnabled()) {
            return [
                $this->getTableName() => ['except' => null, 'as' => $this->dataTableFingerprint()],
                'userSelectedColumns' => ['except' => null, 'as' => $this->dataTableFingerprint() . '-c']
            ];
        }

        return [];
    }

This produces urls that look something like this: http://table-demo.test/?11mbmzx[filters][year]=2022&11mbmzx-c[0]=year

Where 11mbmzx is the fingerprint, or unique alias for the component.

The dynamic link above will apply a filter with the key of year and value 2022 and select to only have the year column displayed.

checking only the year column in the columns▼ dropdown on a table fingerprinted 11mbmzx will put 11mbmzx-c[0]=year into the query string. it will also put the following array into the session:

11mbmzx-columnSelectEnabled => array:1 [▼ 0 => year ]

Query strings will be evaluated first to determined which columns should be displayed, after that the session, followed by the default.

closes #760

In addition to searching, will it be possible to define a filtering column?

More often than not there is a need to filter the table based on values in one of more columns and then search through a scoped result set.

In terms of example provided in documentation:

• filter all users that have a role "admins"
• search by name

Discussed in https://github.com/rappasoft/laravel-livewire-tables/discussions/374

There is a problem when you have two relationships with the same table it always shows the first relationship. I'll try to explain:

I have a model like this:

class Employee extends Model
{
    ...
    public function company(): BelongsTo
    {
        return $this->belongsTo(Company::class, 'company_id', 'id');
    }

    public function related_company(): BelongsTo
    {
        return $this->belongsTo(Company::class, 'related_company_id', 'id');
    }
    ...
}

I have a UserTable component with this piece of code

...
Column::make("Id", "id"),
Column::make("Com. Id.", "company_id"),
Column::make("Company", "company.name"),
Column::make("Rel. Id.", "related_company_id"),
Column::make("Rel. Company", "related_company.name"),
...

It shows something like this...

The last column in the first line shows "Company 3" when related_company_id = 2. If I remove two first lines, I have something like this

In this case, the column shows the correct value of the related table.

This is cause by the same underlying issue as https://github.com/rappasoft/laravel-livewire-tables/issues/719

th classes on sortable columns have no effect.

The following line is hard coding the classes on the sort button:

https://github.com/rappasoft/laravel-livewire-tables/blob/6e30f7c510bc5f08eb53cf776de57634e29b554e/resources/views/components/table/th.blade.php#L24

Options to fix:

1. Add another method to call from configure like setSortButtonAttributes
2. Merge or override classes from the $customAttributes set in setThAttributes.
3. Leave out the duplicated classes that are targeting the text and inherit them, or I should say let them cascade from the th parent.

Options 3 may be the simplest. However I am not 100% on the predictability as to which classes would or should actually affect the text inside the button, and this may not always achieve the desired outcome.

Option 2 may not be the cleanest. The class lists aren't identical so the happy medium might need to be found somehow between text targeting and block targeting classes.

Perhaps the most elegant solution would be to use option one, and also explode the button into another blade view, or component as it were, rather than adding another $customAttributes variable to the th component. $customSortButtonAttributes ? :shrug:

@rappasoft Will you be accepting PR's for this issue?

P.S (Added) I would like to mention: aside from his little quirk the new configure api in v2 is just very very nice. Thank you for that!

All Submissions:

• [x] Have you followed the guidelines in our Contributing document?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

1. [x] Does your submission pass tests and did you add any new tests needed for your feature?
2. [ ] Did you update all templates (if applicable)?
3. [ ] Did you add the relevant documentation (if applicable)?
4. Did you test locally to make sure your feature works as intended?

Changes to Core Features:

• [x] Have you added an explanation of what your changes do and why you'd like us to include them?
• [ ] Have you written new tests for your core changes, as applicable?
• [x] Have you successfully ran tests with your changes locally?

When sorting a relational column, the table wouldn't actually sort. Changing the query to use a backquote (`) instead of a double quote (") seems to fix this.

When updates composer all the tables shows this error, just needs to add this property to the Main DataTableComponent to solve it

TypeError count(): Argument #1 ($value) must be of type Countable|array, null given

All Submissions:

• [ ] Have you followed the guidelines in our Contributing document?
• [ ] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

1. [ ] Does your submission pass tests and did you add any new tests needed for your feature?
2. [ ] Did you update all templates (if applicable)?
3. [ ] Did you add the relevant documentation (if applicable)?
4. Did you test locally to make sure your feature works as intended?

Changes to Core Features:

• [ ] Have you added an explanation of what your changes do and why you'd like us to include them?
• [ ] Have you written new tests for your core changes, as applicable?
• [ ] Have you successfully ran tests with your changes locally?

Hi,

First off, great package!

We're using livewire tables (currently 20+ cruds) extensively thoughout a new project and are experiencing issues with columns not showing by default in the tables. Sometimes one or two columns will display, sometimes all columns will display and sometimes no columns at all will display.

I've tried adding $this->setColumnSelectStatus(true); into the configure method, but this doesn't appear to have any effect.

One possible thought is quite a few of the tables contain the same column names i.e. title, description, enabled etc and I notice that you're creating the session key by md5 hashing the column name, so I don't know whether this might be affecting things?

Any thoughts?

I've added the make:table command. You just pass a class name and it scaffolds out a stub that helps you get started.

Hopefully this is pretty self explanatory. I used a lot of the code and approach as the Livewire make command.

Sorry I don't have any tests.

All Submissions:

• [Y ] Have you followed the guidelines in our Contributing document?
• [ Y] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

1. [ Y] Does your submission pass tests and did you add any new tests needed for your feature?
2. [Y ] Did you update all templates (if applicable)?
3. [Y ] Did you add the relevant documentation (if applicable)?
4. [Y] Did you test locally to make sure your feature works as intended?

Changes to Core Features:

• [] Have you added an explanation of what your changes do and why you'd like us to include them?
• [] Have you written new tests for your core changes, as applicable?
• [] Have you successfully ran tests with your changes locally?

Changes relate to the SlideDown filter layout

Defauilt value is set to false in WIthFilters, and will show it as closed

public bool $filterSlideDownDefaultVisible = false

Two configuration options added for the configure() function

    // Shorthand for $this->setFilterSlideDownDefaultStatus(true)
    $this->setFilterSlideDownDefaultStatusEnabled();

// Shorthand for $this->setFilterSlideDownDefaultStatus(false)
    $this->setFilterSlideDownDefaultStatusDisabled();

  public function setFilterSlideDownDefaultStatus(bool $status): self
  {
      $this->filterSlideDownDefaultVisible = $status;

      return $this;
  }

WithFilters

// Adding filter for use in wireable
public bool $filterSlideDownDefaultVisible = false;

views/components)/wrapper.blade.php

Adjusted for filterOpen reflecting wire value

    @if ($component->isFilterLayoutSlideDown())
        wire:ignore.self x-data="{ filtersOpen: $wire.filterSlideDownDefaultVisible }"
    @endif

Relevant tests & Helper Functions created within FilterConfigurationTest and FilterHelpersTest

These set the initial value of the "filtersOpen" using ALpine: wire:ignore.self x-data="{ filtersOpen: $wire.filterSlideDownDefaultVisible }"

As the initial value is set only, it will not reset to default upon refresh.

This was a change implemented via the coreui update.

All Submissions:

• [ ] Have you followed the guidelines in our Contributing document?
• [ ] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

1. [ ] Does your submission pass tests and did you add any new tests needed for your feature?
2. [ ] Did you update all templates (if applicable)?
3. [ ] Did you add the relevant documentation (if applicable)?
4. Did you test locally to make sure your feature works as intended?

Changes to Core Features:

• [ ] Have you added an explanation of what your changes do and why you'd like us to include them?
• [ ] Have you written new tests for your core changes, as applicable?
• [ ] Have you successfully ran tests with your changes locally?

All Submissions:

• [ ] Have you followed the guidelines in our Contributing document?
• [ ] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

1. [ ] Does your submission pass tests and did you add any new tests needed for your feature?
2. [ ] Did you update all templates (if applicable)?
3. [ ] Did you add the relevant documentation (if applicable)?
4. Did you test locally to make sure your feature works as intended?

Changes to Core Features:

• [ ] Have you added an explanation of what your changes do and why you'd like us to include them?
• [ ] Have you written new tests for your core changes, as applicable?
• [x] Have you successfully ran tests with your changes locally?

Background

I've started testing this library today and ran into an issue where morphOne relations weren't supported by this library. I found this PR ( #844 ) which was supposed to fix the issue. As can be seen in the comment I posted there, the PR fixes the errors and it is able to successfully retrieve the data. Unfortunately, even with the PR, the sorting wasn't working for me.

The potential issue

After some digging, I found the following code:

# vendor/rappasoft/laravel-livewire-tables/src/Traits/WithSorting.php:78
if ($column->hasSortCallback()) {
    $this->setBuilder(call_user_func($column->getSortCallback(), $this->getBuilder(), $direction));
} elseif ($column->isBaseColumn()) {
    $this->setBuilder($this->getBuilder()->orderBy($column->getColumnSelectName(), $direction));
} else {
    $this->setBuilder($this->getBuilder()->orderByRaw('"'.$column->getColumnSelectName().'"' . ' ' . $direction));
}

Here the ordering section is added to the builder. Whilst I don't fully understand what (and why) these conditions exist and what they're supposed to do, I noticed the last line included this:

'"'.$column->getColumnSelectName().'"'

I also logged my builder ->toSql() to see what was happening and this was (the relevant part of) my SQL:

select
    ...
from `counsellors`
    left join `users` on `users`.`userable_id` = `counsellors`.`id`
order by "user.name" desc

Now here we can see the order by clause to be order by "user.name". And this is where the issue comes from. The key used for ordering is a string " ... " and not a reference to the field ` ... `.

Changing the above line to the line below fixes the issue and it all seems to work like a charm!

$this->setBuilder($this->getBuilder()->orderByRaw('`'.$column->getColumnSelectName().'`' . ' ' . $direction));
#                                                 ^^^                                ^^^