Add filter patterns

[mtrezza]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

Combinations of filters that are set in the data browser are lost when navigating away or reloading the dashboard.

Feature / Enhancement Description

Add feature to set preset filter patterns via filter dialog and preset filter patterns via dashboard configuration.

Example Use Case

A filter pattern that finds objects in the _User class where createdAt >= 10 days ago && updatedAt <= 1 day ago

The filer dialog could look like this, with existing buttons less verbose, so there is enough space for a 4th button:

The dashboard config could look like this:

const dashboard = ParseDashboard({
  filters: [
      {
         title: 'Recently deleted users', // The filer pattern title in the filter menu
         classes: ['_User'] // The classes for which the filter will be available; should accept regex to allow for all with `.*`
         filter: [ // The filter pattern as array (is filter order preserved)?
           {
             key: 'createdAt',
             condition: 'gte', // Reuse the syntax that is already used internally
             value: '2022-03-01T00:00:00.000Z'
           },
           {
             key: 'updatedAt',
             condition: 'lte', // Reuse the syntax that is already used internally
             value: '2022-03-10T00:00:00.000Z'
           }
         ]
      }
  ],
});

Alternatives / Workarounds

Enter filter pattern manually (status quo).

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[dblythy]

Is this similar to #2041?

[mtrezza]

Uh, a year has passed and I've added it again; at least this one has a screenshot and a suggestion for the config syntax.

#2041 is similar but not the same; it's just more in the idea of a database view. Essentially the same functionality, but maybe a different layout suggestion. I've added a screenshot in the issue there, to show the different UI. Maybe both feature can coexist and share much of the config parsing logic?

[mtrezza]

A key difference between this issue and #2041 is that "Filter Views" in #2041 are there permanently, which may be unwanted for rarely used filter patterns.

For example, a specific filter patterns is used once in a while. The pattern has a bad DB performance because it's not indexed. Indexing however wouldn't make sense for this rarely used pattern, because maintaining the indices continuously would mean a high constant strain the DB. If this rare pattern is added as a "Filter View", then the count operation next to the filter view triggers this bad performing query too often.

[mtrezza]

I think this can be closed with #2404, which addresses a combination of #2041 and this issue.