Feature Idea: Filters

[minthemiddle]

• Say you have a column with colors
• You want to have a dropdown with available colors and filter on the selected
• Or you have a created_at column and want to filter on timeframe (this year, this month, today)
• These filters should work in combination with search, so you could find all records that are blue and from today

[coryrose1]

Thanks @minthemiddle , this is definitely something to think through.

We'll need multiple select dropdowns if there are multiple filters. At the least there would need to be a "column" select and then another "field/option" select like so:

<select>
  <option>Color</option>
  <option>Created At</option>
</select>
... @if statements to see if color or created_at selected... we'll assume color is selected
<select>
  <option>Red</option>
  <option>Blue</option>
</select>

One way to handle this is like the original jQuery datatables example for column filtering, with a select dropdown above/below each "filterable" column.

Another consideration is the option set. Do we retrieve these from the database or are they user-input? I think somehow the user needs to define the options for a few reasons.

1. Otherwise we'd need to run additional queries to generate those options (i.e. select distinct(color) from whatever_table)
2. The user may/may not want to filter by all colors in the dropdown, maybe only certain colors in the dropdown
3. On handling things like dates.... do we supply defaults like you mentioned, today, past week, etc? They are sort of context dependent.

The query builder in LivewireModelTable would need to be extended to allow the clauses from these filters to be passed through.

The user would need to define how the options affect the query, such as a public $filters array... then a parser would be needed to break out $filters.

For brainstorming purposes...

public $filters = [
  [
    'color' => [
      'Red' => 'red',
      'Blue' => 'blue',
    ],
    'created_at' => [
      'Today' => Carbon::now()->toDateString(),
      'This Year' => ['>=', Carbon::now()->startOfYear()->toDateString(), '<', Carbon::now()->endOfYear()->toDateString()],
    ]
  ]
];

When the option is a string, int, datetime we can add a where clause:

->where('color', 'red');

When it's an array we can pass the operators. Can be multi-clause:

->where('created_at', '>=', Carbon::now()->startOfYear()->toDateString())
->where('created_at', '<', Carbon::now()->endOfYear()->toDateString());

Any thoughts on that approach?

[minthemiddle]

@coryrose1 I strongly support the idea that the user has to define the options herself. public $filters also looks good already, it's easy to understand what this does and how you define the options.