Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: passing filters to registries through $state.params #1935

Closed
jniles opened this issue Aug 3, 2017 · 2 comments
Closed

proposal: passing filters to registries through $state.params #1935

jniles opened this issue Aug 3, 2017 · 2 comments
Assignees

Comments

@jniles
Copy link
Collaborator

jniles commented Aug 3, 2017

We have begun to experiment with filters that are applied to a registry through $state parameters. For example, the Cash Registry implements them by:

  1. Adding filters and display to the route.
  2. Assigning the values to Cash.filters at startup.

This was a good first implementation, but has a number of drawbacks:

  1. 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.
  2. It isn't clear which filters take precedence - the cached ones or the $state ones? Can the $state ones replace default filters?
  3. 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:

$stateProvider.state('someState', {
  url : '/xyz',
  controller : 'SomeCtrl',
  templateUrl :'some-template.html',
  params : { filters : [ ] }
});

In the startup method, we can simply check if the filters exist like this:

var hasStateFilters = $state.params.filters.length > 0;

If they do, we load them into the current view:

if (hasStateFilters) {
  ControllerService.filters.replaceFiltersFromState($state.params.filters);
  ControllerService.cacheFilters();
}

The only difference between replaceFilters and replaceFiltersFromState is an extra angular.copy().

A filter would be defined in the usual way:

filters = [
  { key : 'account_id', value :1234 },
  { key : 'patient_uuid', value : 'some-long-uuid' }
];

Other Thoughts

  1. 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.
@jniles
Copy link
Collaborator Author

jniles commented Aug 21, 2017

This was also implemented and got approval in #2018.

@jniles
Copy link
Collaborator Author

jniles commented Sep 26, 2017

This is already largely in use, but I'll keep this open for reference.

@jniles jniles self-assigned this Oct 20, 2017
jniles added a commit to jniles/bhima that referenced this issue Oct 23, 2017
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.

Closes Third-Culture-Software#1935.
bors bot added a commit that referenced this issue Oct 23, 2017
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.
@bors bors bot closed this as completed in #2236 Oct 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant