-
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Enable multiple filter_panel module calls #135
Labels
Milestone
Comments
This was referenced Nov 28, 2022
Acceptance Criteria:
|
18 tasks
Closed
14 tasks
3 tasks
This was referenced May 31, 2023
gogonzo
added a commit
that referenced
this issue
Jun 16, 2023
Closes #135 and #137 1. `FilterStates$srv_active` uses `renderUI` instead of `insertUI`. 2. `teal_slice` has now obligatory `id` field. 3. `teal_slice` object is now a `reactiveValues` which is passed and stored directly to `FilterState`. This `teal_slice` object can be returned using `FilterState$get_state`. This gives possibility that one `teal_slice` object can be present in the same time in multiple `FilterState` object. This simplifies little constructor of `FilterState` as we don't have to have check again assertions on dataname, varname etc. 4. removed `disabled` functionality as it conflicts with module specific feature. Discussed with @lcd2yyz and we decided to develop some alternatives to quickly activate/deactivate filters. See (5) 5. added `set_available_teal_slice` (public) and `ui/srv_available_filters` to link `srv/ui_active` with some reactive list of "available" slices. This gives a possibility to activate/deactivate particular state. This reactive list of states is set in teal which gathers all modules filters and creates a one unique list of available filters. Co-authored-by: Aleksander Chlebowski <aleksander.chlebowski@contractors.roche.com>
closed by #300 |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Why?
We are moving towards module-specific-filter-panel which means that controlling module filters through single UI element is either impossible or too complicated to address.
First obstacle is that we have a single filter panel UI and we are inserting new filters (see observer in FilterStates$srv_active). If you look at this line in FilterStates$insert_filter_state_ui you will understand that location of the HTML element where we insert new card is fixed in the class (so we have a single filter ui module for all teal_modules)
FilteredData
should be still a single-global objectprivate$cards_container_id
should be removedThe text was updated successfully, but these errors were encountered: