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

FilteredData constructor #49

Merged
merged 44 commits into from
Jun 22, 2022
Merged

Conversation

@kpagacz
Copy link
Contributor

kpagacz commented Jun 14, 2022

I do not see a reason to abandon dispatching on TealData or whatever class inherits from it. I think the smart thing to do is to add an ability to dispatch on things other than TealData and leave the current dispatch intact. This conviction stems from my opinion on what teal should do to data passed to the data parameter of teal::init, which is ideally nothing. Leave the data as it is, let the filter panel dispatch on this thing, and it can decide what it can do. In extreme cases, I can imagine a greyed-out filter panel because whatever user passed to data is not supported by the panel, so it basically exposes nothing.

If we do not let it dispatch, then teal has to worry about what to pass to the filter panel to make it work, and it should not be the teal's decision to make. The panel knows best what it can and cannot work with. Otherwise, we get otherworldly calisthenics in teal or teal.data to make it work, like here: https://github.com/insightsengineering/teal/blob/865c01a64b13de7e4d0c6f333efd37e5604fd5f9/R/module_teal.R#L189 (from PR https://github.com/insightsengineering/teal/pull/670/files)

This also would (fingers crossed?) let users create their own init_filtered_state dispatch that could work as an interface between their weird data and the filter panel.

@nikolas-burkoff

This comment was marked as outdated.

Copy link
Contributor

@gogonzo gogonzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filtering parent doesn't affect the child. See efficacy app for example. get_call in CDISCFilteredData has been modified but this call isn't executed anywhere. This means that relationship between reactive parent and child has been lost.

testthat::expect_error(isolate(datasets$get_filter_overview("AA")), "Some datasets are not available:")
testthat::expect_error(isolate(datasets$get_filter_overview("")), "Some datasets are not available:")
testthat::expect_error(isolate(datasets$get_filter_overview(23)), "Some datasets are not available:")
})

testthat::test_that("get_filter_overview returns overview matrix for non-filtered datasets", {
datasets <- get_filtered_data_object()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this test and the following tests fail.

This is what is expected:

image

But we can no longer distinguish that mock_iris is not CDISC and ADSL is CDISC with no parent. Previously the former was DefaultFilteredDataset and the latter CDISCFilteredDataset. Now they are both DefaultFilteredDataset and then either they both have subjs as this branch now creates a CDISCFilteredData object:

image

Or if I change the creation of datasets to use FilteredData we get neither with subjs:

image

Is this change of behaviour OK? More generally it seems like the design we've changed to is fighting against the dispatch mechanisms in R (we have cdisc, non cdisc and MAE data, on the dataset level we have MAE and not MAE and on the data level we have CDISC and not CDISC). I'm OK with this if it's a stepping stone to simplifying the filter panel and removing all the data but I don't really like it Especially trying to understand the logic to get the filter information - maybe this logic can be simplified?

R/FilteredData.R Outdated
#' TODO
#' @param keys TODO
#' @return (`self`) invisibly this `FilteredData`
set_join_keys = function(keys) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be a private now

@github-actions
Copy link
Contributor

github-actions bot commented Jun 20, 2022

Unit Tests Summary

    1 files    28 suites   15s ⏱️
414 tests 414 ✔️ 0 💤 0
719 runs  719 ✔️ 0 💤 0

Results for commit 649fb6d.

♻️ This comment has been updated with latest results.

@github-actions
Copy link
Contributor

github-actions bot commented Jun 20, 2022

Code Coverage Summary

Filename                      Stmts    Miss  Cover    Missing
--------------------------  -------  ------  -------  -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
R/call_utils.R                  156       4  97.44%   142-145
R/CDISCFilteredData.R           153      27  82.35%   113, 122, 126, 140-149, 251-258, 276-279, 285, 350-353
R/choices_labeled.R              49      14  71.43%   19, 30, 35, 45-50, 62, 66-70
R/eval_expr_with_msg.R           16       6  62.50%   8-13
R/filtered_data_wrappers.R       17      17  0.00%    134-169
R/FilteredData.R                440     310  29.55%   131, 215-219, 253, 255, 257, 260, 275-289, 330-344, 464-466, 593-975, 999, 1006-1007
R/FilteredDataset.R             250      84  66.40%   100, 187, 283, 333-373, 442-448, 489-499, 664-706
R/FilterState.R                1362     718  47.28%   160, 353-354, 451, 636-650, 712-762, 903-930, 1068-1177, 1202-1208, 1382-1542, 1666-1671, 1675-1681, 1694, 1698, 1830-1947, 2004-2010, 2023, 2155-2272, 2300-2306, 2319, 2405-2407, 2473-2634, 2663-2669, 2683
R/FilterStates.R               1413     595  57.89%   101, 119, 223, 302, 381, 432-618, 632-633, 751-787, 942-951, 1008, 1074, 1115, 1176-1181, 1316-1437, 1452, 1486, 1554-1559, 1579-1585, 1592-1597, 1604-1605, 1607, 1768-1777, 1810-1817, 1825-1832, 1860-2029, 2069-2075, 2092-2098, 2105-2110, 2118-2119, 2121, 2169-2170, 2251-2369, 2416, 2449, 2470
R/include_css_js.R                5       5  0.00%    12-16
R/init_filitered_data.R          62       0  100.00%
R/MAEFilteredDataset.R          212      59  72.17%   25, 122, 254-330
R/Queue.R                        50      23  54.00%   22, 40-72, 96-113, 154
R/resolve_state.R                23       0  100.00%
R/utils.R                        74      13  82.43%   123-129, 141-146
R/variable_types.R               48      33  31.25%   42-47, 57, 70-105
R/zzz.R                           6       6  0.00%    3-11
TOTAL                          4336    1914  55.86%

Results for commit: 783c15f

Minimum allowed coverage is 80%

♻️ This comment has been updated with latest results

@kpagacz kpagacz self-assigned this Jun 21, 2022
R/FilteredData.R Outdated Show resolved Hide resolved
@nikolas-burkoff
Copy link
Contributor Author

nikolas-burkoff commented Jun 21, 2022

@gogonzo - your review is probably stale now :)

  • add issue to update filter-panel.Rmd currently I've just added a note saying what is out of date

I guess we don't need to do this? As everything is going to be changing a lot now?

  • work out a nice way of specifying keys/join keys for cdisc data so you don't have to specify them all - although this could go to a different issue?

Do you think we need to do this? We could have join_keys = teal::get_cdisc_join_keys() to simplify creating a CDISCFilteredData object - if so I'll create an issue

@kpagacz
Copy link
Contributor

kpagacz commented Jun 21, 2022

What happens with MAE right now? Or are we doing it in another PR?

EDIT: I think there might be a problem with mixing data.frame and MAE objects together with some join keys between them or parent/child relationship. Pretty sure it is going to go wrong.

@nikolas-burkoff
Copy link
Contributor Author

EDIT: I think there might be a problem with mixing data.frame and MAE objects together with some join keys between them or parent/child relationship. Pretty sure it is going to go wrong.

So I think it is going to go the same wrong as it would have done before this PR? Maybe an issue in the backlog?

@@ -104,7 +134,7 @@ FilteredData <- R6::R6Class( # nolint
#' @description
#' Gets variable names of a given dataname for the filtering.
#'
#' @param dataname (`character`) name of the dataset
#' @param dataname (`character(1)`) name of the dataset
#' @return (`character` vector) of variable names
get_filterable_varnames = function(dataname) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw, what is the point of this method? XD

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's overwritten in CDISCFilteredData...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • in FilteredData it doesn't do anything. colnames(data) == filterable_varnames
  • In CDISCFIltereData we don't want child to have duplicated columns. It's actually users request because in ADTTE there are some duplicated columns comparing to ADSL. I foreseen that in the future it might cause some confusion as we can for example build a relationship between movie <-> actor and movie.name with actor.name are duplicated names but not the same thing. Let's discuss this in some time in the future if it will be important.

@gogonzo
Copy link
Contributor

gogonzo commented Jun 21, 2022

  • add issue to update filter-panel.Rmd currently I've just added a note saying what is out of date
    I guess we don't need to do this? As everything is going to be changing a lot now?

We need the update for sure. I'll put this to sprint 60 when we have everything possibly clarified and done.

#52

  • work out a nice way of specifying keys/join keys for cdisc data so you don't have to specify them all - although this could go to a different issue?
    Do you think we need to do this? We could have join_keys = teal::get_cdisc_join_keys() to simplify creating a CDISCFilteredData object - if so I'll create an issue

Let's create the issue but doesn't have to be taken in this increment. #53

@gogonzo
Copy link
Contributor

gogonzo commented Jun 21, 2022

EDIT: I think there might be a problem with mixing data.frame and MAE objects together with some join keys between them or parent/child relationship. Pretty sure it is going to go wrong.

So I think it is going to go the same wrong as it would have done before this PR? Maybe an issue in the backlog?

@nikolas-burkoff is right. Nothing new. If the MAE users complain about this we would know. At this moment it's a gap we can ignore.

@nikolas-burkoff nikolas-burkoff dismissed gogonzo’s stale review June 21, 2022 14:51

out of date review

Copy link
Contributor

@gogonzo gogonzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting FilteredData is simplified as much as it's possible at this moment.

image

Copy link
Contributor

@kpagacz kpagacz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have spent the morning launching the apps from the gallery and I have not noticed anything browfurrowing.

@nikolas-burkoff nikolas-burkoff merged commit a75c135 into main Jun 22, 2022
@nikolas-burkoff nikolas-burkoff deleted the 33_filteredData_constructor@main branch June 22, 2022 10:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Change constructor of the FilteredData to not depend on TealData
4 participants