Pangene Lookup Components #391
Conversation
This preserves some special characters that would otherwise be removed when the values are added to the querystring.
This allows errors that occurred during loading to be reported via the loading element's alert element.
… type This allows errors to be reported even when there are partial results.
The element looks up pangenes for a list of gene identifiers that meet the given constraints.
Specifically, the search success and results info methods were updated to use generic types. This makes the these methods more reusable and independently extensible while making the generic search function and search result types more specific.
This means pagination information is no longer passed to the search function and results are not expected to include pagination information.
Except for annotation because these data are currently missing from the backend.
This label explains that the constraints apply to the genes being looked up, not the input genes.
This makes parsing the results much simpler and implementing pagination trivial.
This required adding genesRegexp and genesLimit properties to the component. These properties are used to implement a custom form field validator for the genes textarea. Lastly, the Lit willUpdate hook is used to decorate the searchFunction and downloadFunction properties when they are set so that the gene identifiers passed to these functions are split using the genesRegexp but the genes textarea text is encoded/decoded verbatim in the querystring parameters.
…the input gene identifier text
…vent Specifically, the original submit event emitted by the wrapped form is now being included in the formEvent property of the custom event's detail object. This allows downstream event handlers to fully utilize the original event.
…apped search form Specifically, the search mixin is using the original event to determine if the download button is what submitted the form.
The pagination component's page was mistakenly being reset to the default page (i.e. 1) for every search.
Mostly just one last kick of the tires. While preparing this PR I found a bit of code that hadn't been committed which is supposedly necessary so one last sanity check would be nice to be sure nothing else has slipped by. |
There was a problem hiding this comment.
One nitpick; can you change the verbiage for the case where the targeted annotations don't have any members in the pangeneset matched by the query gene? Currently given as "No matches found for identifier", we had discussed an alternative via email a while back. otherwise, seems to be working as I would expect.
Whoops, I forgot about that. In the email you suggested "no matching targets found in pangene set for gene x." How do you feel about the subtly different "no matching targets found in a pangene set for gene x"? The prior assumes each gene belongs to a single pangene set whereas the latter does not, which means that's one less thing to remember and fix if/when we end up having multiple pangene sets loaded simultaneously. |
|
sorry, was busy with other things. I feel fine about your subtle verbiage change and in fact tested the component against a version of glycinemine that has two pangenesets loaded concurrently- it works just as expected. |
The future is now I guess. Note that this error will only trigger if no matches are in full the result set, so if a query gene belongs to two pangene sets but only has matches for one of them then the error will not be shown. This scenario and the error verbiage are actually handled outside of the component so this is the sort of thing that can be fixed in the future without having to roll a new release of the components library. |
This PR adds a pangene lookup component and various changes to support the component, including: