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

feat: beacon validation and errors #125

Merged
merged 21 commits into from
Dec 12, 2023
Merged

Conversation

gsfk
Copy link
Member

@gsfk gsfk commented Nov 9, 2023

Form error checking and user feedback for Beacon search UI:

  • block submission of incorrect forms
  • show user feedback for errors in the form
  • show user feedback for errors returned by beacon
  • better tooltip helptext

Some new text requires translation.

The sheer amount of instructions and feedback suggests that the form could probably be more intuitive to use. There is some discussion here in the code.

@gsfk gsfk marked this pull request as ready for review November 9, 2023 14:05
Copy link
Member

@davidlougheed davidlougheed left a comment

Choose a reason for hiding this comment

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

preliminary comment + translations should be in place pre-merge

src/js/components/Beacon/BeaconQueryUi.tsx Outdated Show resolved Hide resolved
@gsfk
Copy link
Member Author

gsfk commented Nov 16, 2023

draft translation pr is here, just needs French portions filled in.

@davidlougheed davidlougheed changed the title Features/beacon validation and errors feat: beacon validation and errors Nov 16, 2023
Copy link
Member

@davidlougheed davidlougheed left a comment

Choose a reason for hiding this comment

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

overall looks good to me with a few minor code style things

// complexity of instructions suggests the form isn't intuitive enough
const VARIANTS_INSTRUCTIONS_TITLE = 'Variant search';
const VARIANTS_INSTRUCTIONS_LINE1 =
'To search for all variants inside a range: fill both "Variant start" and "Variant end", all variants inside the range will be returned. You can optionally filter by reference or alternate bases.';
Copy link
Member

Choose a reason for hiding this comment

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

i guess bento_public linting doesn't enforce this, but i'd prefer a max 120-char line width here

// https://docs.genomebeacons.org/variant-queries/

// as an alternative, we could require "end" always, then form logic would be less convoluted
// just set start=end to search for SNPs
Copy link
Member

Choose a reason for hiding this comment

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

when we eventually have chrom autofill from gohan/ref service, we could use the information in the ref service to auto-fill end to the end of the chromosome if it's unset (and change it if the user changes the chromosome to the length of the new chromosome if it === the previous chrom length) or something like this. for now, i think this is fine even though it's convoluted.

Copy link
Member Author

Choose a reason for hiding this comment

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

Do people really want to search entire chromosomes?

Copy link
Member

Choose a reason for hiding this comment

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

not really no, that's true

Copy link
Member Author

Choose a reason for hiding this comment

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

could perhaps work for genes though I guess

launchEmptyQuery();
};

const SearchToolTip = ({ text }: { text: string }) => {
const handleValuesChange = (_: Partial<FormValues>, allValues: FormValues) => {
form.validateFields(['Chromosome', 'Variant start', 'Variant end', 'Reference base(s)', 'Alternate base(s)']);
Copy link
Member

Choose a reason for hiding this comment

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

this list of fields is used once above too for const empty - maybe worth factoring out?

Copy link
Member

Choose a reason for hiding this comment

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

(all fields, i guess?)

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, there are a lot of variant form names lying around in the code (and not too helpfully the correct name for this collection is something like allVariantFormFieldsExceptAssemblyID... )

In empty we're checking each name individually, where in validate fields we're using all names together. So a possible refactor is something like:

const empty = !allVariantFormFieldsExceptAssemblyID.some(field => formValues[field])

but i'm not sure this is better....

Copy link
Member

Choose a reason for hiding this comment

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

could use the every() function of the array (plus a boolean cast of !! for formValues[field])

in this case, why is assembly ID not validated?

Copy link
Member Author

Choose a reason for hiding this comment

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

The reasoning behind the variants form is that if you want to search variants you fill it in, and if you don't, you leave it blank. So the if the form is blank it's ignored, and none of the rules about required fields are applied.

However, the form is almost never blank, since the assembly ID field is already filled for you in the (very common) case where there is only one assembly to search from. That's why it's treated separately from everything else.

src/js/components/Beacon/BeaconQueryUi.tsx Show resolved Hide resolved
import React, { Dispatch, SetStateAction } from 'react';
import { Alert } from 'antd';

const BeaconErrorMessage = ({ message, setErrorAlertClosed }: BeaconErrorMessageProps) => {
Copy link
Member

Choose a reason for hiding this comment

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

I think a more generalizable parameter format would be to accept an onClose function, which is bound directly to the Alert - rather than passing a state setter down. this brings it more in line with antd components, and we could in the future change the onClose behaviour to do additional/different things.

Copy link
Member Author

@gsfk gsfk Dec 11, 2023

Choose a reason for hiding this comment

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

Ah, the state is here only to force a form re-render, it doesn't actually carry any useful information.

Copy link
Member

Choose a reason for hiding this comment

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

yes the state is fine, I mean that the prop on BeaconErrorMessage should be onClose and that should be bound to the state update function where this component is used

launchEmptyQuery();
};

const SearchToolTip = ({ text }: { text: string }) => {
const handleValuesChange = (_: Partial<FormValues>, allValues: FormValues) => {
form.validateFields(['Chromosome', 'Variant start', 'Variant end', 'Reference base(s)', 'Alternate base(s)']);
Copy link
Member

Choose a reason for hiding this comment

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

could use the every() function of the array (plus a boolean cast of !! for formValues[field])

in this case, why is assembly ID not validated?

Copy link
Member

@davidlougheed davidlougheed left a comment

Choose a reason for hiding this comment

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

lgtm

@gsfk gsfk merged commit 707fba6 into main Dec 12, 2023
2 checks passed
@davidlougheed davidlougheed deleted the features/beacon-validation-and-errors branch December 22, 2023 18:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants