-
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
Orthogroup tree table 1254 fixes #1259
Orthogroup tree table 1254 fixes #1259
Conversation
…ogroup-tree-table__1254-fixes
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.
I think this is mostly great. I made several comments, but I don't think any are show stoppers.
@@ -15,7 +18,7 @@ export interface SelectListProps<T> extends CheckboxListProps<T> { | |||
instantUpdate?: boolean; | |||
} | |||
|
|||
export default function SelectList<T>({ | |||
export default function SelectList<T extends ReactNode>({ |
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 seems strange to me. T
is the type of the value. I don't think we ever want that to be a ReactNode. I think we should have T extends string
, to be honest.
The change you made for buttonDisplayContent
is perfect.
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.
Thanks. I'll try that, but it was my understanding that T needed to be something "compatible with" ReactNode.
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.
I think of value
as what would be included in a form request, which is always a string. A number could also work, but I'm not convinced we need to do that.
This would be a breaking change, but I'm not sure if it would actually break anything.
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.
I've fixed it as you suggested*. If it's a breaking change, it hasn't broken anything within this repo at least!
- I messed up the commits and it went in as two different commits, but the commit messages hopefully explain all.
import { | ||
areTermsInStringRegexString, | ||
parseSearchQueryString, | ||
} from '../../../../../../../libs/wdk-client/lib/Utils/SearchUtils'; |
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.
} from '../../../../../../../libs/wdk-client/lib/Utils/SearchUtils'; | |
} from '@veupathdb/wdk-client/lib/Utils/SearchUtils'; |
(mesaRows.length !== sortedRows.length || | ||
mesaRows.length !== leaves?.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.
Are both comparisons necessary?
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.
Yes, I think so.
sortRows()
returns the protein table rows in tree leaf order. Proteins that are missing from the tree are an obvious problem. But the tree can also be bigger (more leaves) than the protein table (though Rich says it won't happen) - it's best to play on the safe side.
Just using mesaRows.length !== leaves?.length
won't protect against a protein table of X rows and a tree with X leaves, but where none of the proteins/leaves match each other.
<span> | ||
A data processing error has occurred on our end. We apologize for | ||
the inconvenience. If this problem persists, please{' '} | ||
<Link to="/contact-us">contact us</Link>. |
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.
Maybe add target="_blank"
const warningText = | ||
filteredRows.length > MAX_SEQUENCES_FOR_TREE || | ||
filteredRows.length < MIN_SEQUENCES_FOR_TREE ? ( | ||
<span> | ||
To see a phylogenetic tree please use a filter to display between{' '} | ||
{MIN_SEQUENCES_FOR_TREE.toLocaleString()} and{' '} | ||
{MAX_SEQUENCES_FOR_TREE.toLocaleString()} sequences | ||
</span> | ||
) : filteredRows.length < sortedRows.length ? ( | ||
<span> | ||
Note: The ortholog group's phylogeny has been pruned to display only the | ||
currently filtered proteins. This may differ from a tree constructed{' '} | ||
<i>de novo</i> using only these sequences. | ||
</span> | ||
) : undefined; | ||
|
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.
I have a concern about putting this new message in the same place as the other message. It gets lost. Wouldn't it make more sense to add this to the table description where we describe the ability to filter?
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 mean it gets lost because it's the same colour and position as the "too many proteins" message that was almost certainly there just before they filtered?
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.
I'm not going to tackle this tonight. I don't really see it as a problem, personally. But we can discuss tomorrow.
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 mean it gets lost because it's the same colour and position as the "too many proteins" message that was almost certainly there just before they filtered?
Yes, that was my thinking. Let's leave it as-is and see if others raise it as an issue.
…ogroup-tree-table__1254-fixes
…boxList/SelectList generics 1 of 2
I'd be grateful if you could have a quick look at the latest changes, @dmfalke - thanks! |
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 looks great. I made one last suggestion. There may be a couple of other places that we should use MIN_SEQUENCES_FOR_TREE
. Otherwise, I think this is good to go.
@@ -98,7 +98,10 @@ export function RecordTable_Sequences( | |||
const numSequences = mesaRows.length; | |||
|
|||
const treeResponse = useOrthoService( | |||
(orthoService) => orthoService.getGroupTree(groupName), | |||
(orthoService) => { | |||
if (numSequences < 3) return Promise.resolve(undefined); |
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.
Should probably use MIN_SEQUENCES_FOR_TREE
here.
Resolves #1254
I looked into improving the responsiveness of the table paging controls with useDeferredState, but it was not possible due to the memoisation of
mesaState
- which has a mix of "slow" and "volatile" dependencies. I wonder if that memoisation isn't actually necessary? (Answer: I removed it and this reintroduced the janky search field checkboxes...)