-
Notifications
You must be signed in to change notification settings - Fork 8
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
Enable search for new samples query #163
Enable search for new samples query #163
Conversation
We previously used dataloader to make a single query for samples via the OGM. Otherwise, the `samples` and `samplesConnection` sub-queries would be call it twice. With the new approach, we use two slightly different queries to get samples data and the count of samples. We could use dataloader to access the oncotree cache, but this operation is very fast (< 0.05ms).
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
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.
One thing I've noticed while testing is that all columns get downloaded on the samples page even when there are columns hidden. Is this a TODO for a later card?
Related to this: there still seems to be a cap of 500 samples here when downloading from the samples page
To replicate: I used search term "BRCNOS" which should return 804 samples (dev server)
@ao508 Thanks for catching that. Adding it to the next PR's todos now.
This is one of my TODOs for the next PR. You can find this list in this PR's description here for now. I'll add this list to the next Zenhub card after we finish with this PR. |
import styles from "./records.module.scss"; | ||
import { getUserEmail } from "../utils/getUserEmail"; | ||
import { openLoginPopup } from "../utils/openLoginPopup"; | ||
import { Title } from "../shared/components/Title"; | ||
import { BreadCrumb } from "../shared/components/BreadCrumb"; | ||
import { useParams } from "react-router-dom"; | ||
import { DataName } from "../shared/types"; | ||
import { parseUserSearchVal } from "../utils/parseSearchQueries"; | ||
|
||
const POLLING_INTERVAL = 2000; |
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.
Would you mind increasing this to 2700 (45 seconds)? I'm hoping that the extra interval of time will result in less "blinking" when viewing and updating samples for a request/patient/cohort
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.
This is in milliseconds, so this is currently at 2 seconds. I just bumped it up to 5 seconds in the dev dashboard. Let me know if you're still seeing it. If you're able to record a clip of this "blinking", I'm happy to take a look as well
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.
(If this blinking is a big problem, we can consider using websocket to display real-time sample updates instead. More optimal as we don't continuously refetch for no reason.)
…ampleId column to the front
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.
Looking good, thank you!
This PR includes the work for cards #1224 and #1281, with most changes for the former.
This enables search for the new samples query written in #162.
High-level details of the new flow:
DashboardSamples
TODOs in the next PR:
tableElements.tsx
files