You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was a good first implementation, but has a number of drawbacks:
The API of filters and display isn't obvious what goes where. It turns out, display is never used. I believe this was a hold-over from the old way of specifying filters.
It isn't clear which filters take precedence - the cached ones or the $state ones? Can the $state ones replace default filters?
Only one filter can ever be used at a time from $state (in the current implementation).
Design
Building off the current implementation, I propose we adopt a new way of passing filters from $state. Every registry that accepts external filters will provide a top-level filters array in the parameters, defined in this way:
We could optionally specify if the filters should be merged, overwritten, or temporary (not cached). I'm not sure what the best implementation should be.
The text was updated successfully, but these errors were encountered:
This commit implements the recommendations of Third-Culture-Software#1935 on all registries.
This allows all linked registries to send multiple filters through
$state parameters as necessary.
ClosesThird-Culture-Software#1935.
2236: chore: use uniform interface for $state filters r=jniles a=jniles
This commit implements the recommendations of #1935 on all registries. This allows all linked registries to send multiple filters through $state parameters as necessary.
Closes#1935.
We have begun to experiment with filters that are applied to a registry through $state parameters. For example, the Cash Registry implements them by:
This was a good first implementation, but has a number of drawbacks:
filters
anddisplay
isn't obvious what goes where. It turns out,display
is never used. I believe this was a hold-over from the old way of specifying filters.Design
Building off the current implementation, I propose we adopt a new way of passing filters from
$state
. Every registry that accepts external filters will provide a top-levelfilters
array in the parameters, defined in this way:In the startup method, we can simply check if the filters exist like this:
If they do, we load them into the current view:
The only difference between
replaceFilters
andreplaceFiltersFromState
is an extraangular.copy()
.A filter would be defined in the usual way:
Other Thoughts
The text was updated successfully, but these errors were encountered: