-
Notifications
You must be signed in to change notification settings - Fork 0
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
Disable apps based on study metadata #732
Conversation
Dear reviewers, Please pay close attention to
Thank you! |
@reviewers i added some studies in the description to help with testing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
packages/libs/eda/src/lib/core/components/computations/plugins/abundance.tsx
Outdated
Show resolved
Hide resolved
packages/libs/eda/src/lib/core/components/computations/plugins/correlationAssayMetadata.tsx
Outdated
Show resolved
Hide resolved
Co-authored-by: Dave Falke <[email protected]>
Ahh this looks much much better. Good idea. I'll see if i can get the "Not applicable..." text to show up a bit more... to be continued! And @dmfalke thank you for your other suggestions - they've all been added! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks great but no correlation apps are enabled for DailyBaby 😞
It should have the Correlation "Discover taxa or genes correlated with metadata" app, right? Because it has 1:1:1 PRM:Samples:Assays and there is a continuous Age variable on PRM.
const studyHasCollections = entities.some( | ||
(e): e is StudyEntity & Required<Pick<StudyEntity, 'collections'>> => | ||
!!e.collections?.length | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How important is the type predicate assertion here? If we were filtering and then doing something with the result (especially if an array result of StudyEntities), it would be useful. But I'm not sure the extra complication wins us anything here because the some
just returns true/false.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. Simplified in the latest commit!
const entities = entityTreeToArray(studyMetadata.rootEntity); | ||
const hasMetagenomicData = | ||
entities.filter((entity) => entity.id === 'OBI_0002623').length > 0; // OBI_0002623 = Metagenomic sequencing assay | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we also need to check for non-zero length collections
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you're right we should. I was making the assumption that if that entity existed, then it would have a collection. But just becasue that's generally true doesn't mean it will always be the case! I'll add a check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, an entities.find(...) !== undefined
might be very very slightly marginally more efficient! (because it stops the search as soon as it finds something - but these arrays are tiny, so it will make very little difference)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or I guess entities.some(...)
works too!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's still possible that the study with collections and a OBI_0002623 assay with no collections could get through, I think?
Maybe just this?
const hasMetagenomicData = entities.some((entity) => entity.id === 'OBI_0002623' && !!entity.collections?.length);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ack you're right! All fixed now!
I was interested so I looked into the difference in performance between some
and find
. It seems some
is ever so slightly more efficient, since find
calls some
. But you're right it wouldn't matter on an array of this size anyway.
'EUPATH_0000809', | ||
'EUPATH_0000813', | ||
'EUPATH_0000812', | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a long term plan (e.g. ticket) to annotate entities appropriately to reduce the amount of hardcoded entity IDs? (If that's agreed to be a plan.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great question. I just made a ticket for it but i think it could use some more discussion. There wasn't originally a long-term plan because i didn't think that i would end up needing these assay ids at all until i got into the implementation.
To completely remove the hardcoded ids we'd need to add the following annotations:
- To the study, add
hasMetagenomicData
. I think there's a similarhasMapData
annotation? - To each entity, add
isAssay
. Or i suppose it could be something likeentityType = 'assay'
, if there are other entity types that might be useful to us.
Also open to other solutions!
(entity) => entity.isManyToOneWithParent | ||
); | ||
const oneToOneAncestors = ancestorEntities.slice( | ||
1, // removing the assay itself |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we assume there are no continuous 'metadata variables' on the same entity as the assay entity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. That assay entity should only have assay data.
@dmfalke what do you think of the below? I faked transparency by lightening the gray of the text to a hue that matches what it'd look like if it was transparent. |
Oh no! Turns out that Age variable is an integer, not a number, so i was missing it. Fixed in the latest commit. Good catch @bobular ! |
Transparency faking looks good to me. I don't think there's another way. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me (though I haven't fired it up again to test).
I left one pedantic logic query.
const entities = entityTreeToArray(studyMetadata.rootEntity); | ||
const hasMetagenomicData = | ||
entities.filter((entity) => entity.id === 'OBI_0002623').length > 0; // OBI_0002623 = Metagenomic sequencing assay | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's still possible that the study with collections and a OBI_0002623 assay with no collections could get through, I think?
Maybe just this?
const hasMetagenomicData = entities.some((entity) => entity.id === 'OBI_0002623' && !!entity.collections?.length);
Resolves #731 , child of #407
The two correlation apps require particular data to run. Some studies don't have these data, so for those cases we want to show a disabled app. More specifically,
I also used the same architecture for the above checks to address #723
To Dos
For testing, some helpful studies include: