search

statgen / fivex

Interactive eQTL visualizations
MIT License
13 stars 3 forks source link

Sort gene-based categories on PheWAS by TSS #13

Closed pjvandehaar closed 5 years ago

pjvandehaar commented 5 years ago

@abought , do you think this category-ordering would be valuable in LZ? LZ could support only ascending sort, in which case the pheget server could send a field tss = pos - tss_distance. Category-ordering is probably useful elsewhere, though I'm not sure where. If LZ also had a field to sort within each category, then it could be used in PheWeb.

abought commented 5 years ago

Broadly, I think a secondary sort feature could be helpful.

Could you provide a one sentence description of the intended outcome? This will help me to give better feedback, including on whether the code would meet that general goal.

Eg, "support secondary sort on more than one field", or "support sorting on something other than how categories are defined".

As for synthetic fields to control sort order- I see two alternatives:

  1. If you needed a totally custom sort field, a custom datasource could add a new field using the annotateData method (of a custom datasource) on the frontend; no need to add UI-only fields of cryptic purpose to the underlying api.

  2. If the sort behavior is really simple (asc/desc), we could add some logic to control the sort order, eg with + or - modifiers on the field name.

What's the intended goal? Happy to help write something to get us there.

pjvandehaar commented 5 years ago

I don't see a need to use more than one field to order the categories. Likewise for ordering the points within each category. I think it's best to keep those two levels of sorting separate. This PR orders the categories. It ignores the order of points within a category (which is what I thought "secondary sort" referred to).

In pheget's category=symbol PheWAS, categories should be ordered by their TSS (which is equivalent to ordering descending by tss_distance) and then within each category the tissues should be sorted alphabetically. Vice versa for category=tissue. In pheweb's PheWAS, categories are sorted by their smallest ICD codes (which seems too single-use for integration into core LZ but is easy for me to add using annotateData), and within each category points are sorted by ICD code.

Perhaps it's best to just finish this feature for pheget. We can upstream category-ordering (and add within-category-sorting) to LZ once we're done with pheget's PheWAS or whenever sorting comes up again, after we've had time to work with it.

abought commented 5 years ago

Heads up: I'll be rebasing this branch to resolve merge conflicts, (and make other changes)- let me know if there are last minute changes before merge.

abought commented 5 years ago

As we add more display and sort options, I think it would be really helpful to show which options are active at any given time. This is particularly the case for something like TSS distance, which only seems to be used in "group by symbol" mode.

When we sort by symbol, would it make sense to mark the dividing line where TSS distance is ~0? It seems that "look for the closest gene" is a common starting point, and the sorted axis doesn't quite display that clearly.

pjvandehaar commented 5 years ago

I like the idea of a symbol on the x-axis indicating where tss_distance = 0 is.

To see what options are active, I usually just check layout.panels[0].data_layers[0] and cross-reference with the code in groupByThing and switchY. Do you have a different method in mind?

This seems ready to rebase/merge to me. What do you think?

abought commented 5 years ago

To see what options are active, I usually just check layout.panels[0].data_layers[0] and cross-reference with the code in groupByThing and switchY. Do you have a different method in mind?

One option is to have groupByThing and switchY set the "active options" list directly- for right now, these options are mutually exclusive. (the selling point of these functions is that the state currently changes only in one well-defined, predictable manner)

The more maintainable option long term would be the UI was written in a reactive way (eg vue), so that the changes were connected but in a readable way. This could be done purely in JS for now.

Before I invest too much time in the complex solution, I think it would be healthy to sketch the page beyond the scatter plot, and then write the controls accordingly as we have a plan that connects our list of features into a cohesive whole.