filtered-search: tree-shakable criteria

[spike-rabbit]

I am planning to not drop the old APIs right away. Instead we can have a longer transition period.

The FS currently supports many different types of values:

• string (with and without suggestions)
• select
• multi-select
• number (float and integer)
• date (with and without time)

We should add/enhance:

• tree-multi-select
• (multi)-select (object as keys and custom actions, similar to si-select)
• there could be more / we should be ready

Since we have so many types, we should consider reshaping our API to be tree-shakeable. Otherwise, we will end up having a huge component with lots of features which are barely used all at once by clients.

As a reminder, filtered-search currently allows static criteria and lazy-loaded criteria.

Static criteria

For static criteria, we should build a very clean API:

<si-filtered-search>
  <si-fs-string-criterion name="country" label="Country" />
  <si-fs-select-criterion name="city" label="City" [options]="arrayOrProviderFunction" />
  <si-fs-select-criterion name="company" label="Company" />
  ...
</si-filtered-search>

This is probably nicer than the current approach anyway, since apps can also make use of @if / @for and we move configuration into the template instead of code.

Lazy loaded criteria

This is the complicated part. The basic flow is like this:

• filtered-search somehow triggers a search criteria event when the user starts typing
• the application loads the data from the backend
• the loaded criteria definitions are somehow connected to the implementations

My idea is to only provide a very basic interface, as I assume that in most cases static criteria are sufficient. Even when criteria are loaded from the backend, they could still be used in the static way using async pipes or whatever. We only need the lazy loading way if there are so many criteria that they cannot all be fetched at once.

For those remaining cases, we could offer the following:

<si-filtered-search (loadCriteriaDefinitions)="loadCriteriaDefinitions($event.search, $event.usedCriteriaNames)">
  @for(criteriaDefinition of criteriaDefinitions; track criteriaDefinition.name) {
    <si-fs-string-criteria ... />
    ...
  }
</si-filtered-search>

class MyComponent {
  loadCriteriaDefinitions(search: string, names: string[]) {
    // The implementation must load all criteria that match the search + all criteria for the names.
    // We need the names in case an application provided initial values
  }
}

The good thing about this solution is that we almost don't need internal adjustments. We just must be capable of dealing with missing criteria definitions and changes in the list of criteria.

@siemens/siemens-element please provide feedback.

[spliffone]

I would prefer to use singular instead of plural for the naming.

[spliffone]

1. I assume the criteriaDefinitions are a consumer property. How do you indicate a pending/loading state?
2. As an alternative, simply stay with the interceptDisplayedCriteria to show / hide an criterion from the selection
3. How do you address the lazy options? I guess they are more important for consumers

[spike-rabbit]

I would prefer to use singular instead of plural for the naming.

I will adjust the proposal.

1. I assume the criteriaDefinitions are a consumer property. How do you indicate a pending/loading state?

I don't know yet. This is also not possible on the current filtered-search. Maybe just a [loading] input on the FS

2. As an alternative, simply stay with the interceptDisplayedCriteria to show / hide an criterion from the selection

I want to keep interceptDisplayedCriteria. The @if could be more used for static checks like: Does user have access rights to this criteria? Or maybe not at all, but it could be used.

3. How do you address the lazy options? I guess they are more important for consumers

Similar as before, so keeping the input on the si-filtered-search but also have the option to pass them directly to the criterion with the same interface.