Storage of enabled tracks and genomic coordinates when the page is refreshed

[LankyAlec]

/Hi, I have a problem that I can't solve.
I'm building a database that contains CNVs in both Hg19 and Hg38 assemblies. I have created a single page for the Jbrowse where you can move between the two assemblies easily.
The problem is that when you change assembly the default options are restored (including tracks and genomic positions).
Is there a way to store these options?

Also, while I'm at it, I ask you if there is a way to disable the "force load" that appears when the genomic window is very large and make sure that the trace elements appear automatically.

Thank you.

[cmdcolin]

Hi there
It looks like you are using the "embedded widget". This means that you may be able to get the expected behavior by programmatically, but those types of features are not built in. The embedded widget basically relies on the programmer to implement custom behaviors like this.

For example, you mention wanting to keep the same tracks open. You could use a getSnapshot on the object returned by createViewState, and then inspect state.session.views[0].tracks, this will tell you what tracks are open, and then again, when you change assemblies, you could use state.session.views[0].showTrack(trackId) one or more times to match the tracks.

Same thing with the location...

You could get const oldLocStrings=state.session.views[0].visibleLocStrings, this gives you the genomic regions in string form, and then when you change assemblies, you could do state.session.views[0].navToLocString(oldLocStrings). Remember though, the genomic coordinates on hg19 are quite different from hg38, so doing this may not have the exact expected behavior.

Ultimately, the embedded widget relies a lot on the programmer to implement some custom behaviors like this, but the upside is that, you can programmatically manipulate it :) just requires some deep diving into our docs (for example, it's hard to find, but this is the visibleLocStrings doc entry https://jbrowse.org/jb2/docs/models/lineargenomeview/#getter-visiblelocstrings), but welcome to ask questions to help clarify too.

As far as the "force load thing", you can edit your track config to change "maxFeatureScreenDensity": 10," or some large number. This will force it to draw even when the feature density is high. We could maybe adjust our defaults if you think our defaults aren't great. Note that this setting is on the "display", here is an example for the LinearVariantDisplay/VariantTrack. For a FeatureTrack, it would be LinearBasicDisplay instead of LinearVariantDisplay

jbrowse-components/test_data/volvox/config.json

Lines 1541 to 1547 in eafc6f7

	"type": "LinearVariantDisplay",
	"maxFeatureScreenDensity": 0.0006,
	"displayId": "volvox_filtered_vcf_color-LinearVariantDisplay",
	"renderer": {
	"type": "SvgFeatureRenderer",
	"color1": "jexl:get(feature,'type')=='SNV'?'green':'purple'"
	}

For a gene track

[LankyAlec]

Thanks for the quick reply.
I'll try to put into practice what he suggested and let you know

[LankyAlec]

all your tips worked great.

thank you

[cmdcolin]

happy to help!

I also noted that the title of this question mentioned page refresh. As an example of this, our jbrowse-web app stores a JSON.stringify of the getSnapshot of the model in localstorage, and then re-accesses that when the page is refreshed. that way it retains essentially all the information. But, the embedded components like @jbrowse/react-linear-genome-view does not do this as it doesn't make any assumptions about how a user of the library would want to reload the state of the browser, but so the programmer needs to essentially re-implement functionality like that which is kinda tricky, but should be do-able and indeed, programmable.

the jbrowse-web app contains essentially many default sort of assumptions about 'app like' behavior like that refresh behavior, but the @jbrowse/react-linear-genome-view is more of a library and so requires some effort to implement...we could try to provide some helper functions to make it easier for users though. our storybook examples https://jbrowse.org/storybook/lgv/main/ are also a good source of various usages of the embedded components