Skip to content

Migration of code on GenomeBrowser page to use new feature ids

Jump to bottom
Andrey Azov edited this page Apr 30, 2020 · 1 revision

Migration of code on GenomeBrowser page to use new feature ids

Example Genome Browser page urls:

Note:

  • the focus parameter contains id of an object without the genome id (because genome id is in the pathname of the url)
  • in the future, we should remove the /app namespace, because it is not doing anything useful and, as an extra level in the pathname, is an SEO antipattern

Getting example focus object ids from the api

example endpoint: /api/genome/info?genome_id=homo_sapiens_GCA_000001405_27

relevant part of response:

{
  example_objects: [
    {
      id: "ENSG00000139618",
      type: "gene",
    },
    {
      id: "17:63992802-64038237",
      type: "region",
    },
  ]
}

Note: the field on an object here is named id, although later when talking with apis we will use stable_id as query parameter. The reason for doing so is because example objects returned from the endpoint above can be regions, and regions do not have stable ids.

Question: Don't variants also not have stable ids?

Getting further information about focus objects

Getting info and track list for gene

Example endpoints:

  • /api/object/info?genome_id=homo_sapiens_GCA_000001405_27&type=gene&stable_id=ENSG00000139618
  • /api/object/track_list?genome_id=homo_sapiens_GCA_000001405_27&type=gene&stable_id=ENSG00000139618

Notice the stable_id query parameter.

Getting info for region

Information about a region can be extracted on the client based on the focus id. Initially, we thought that focus ids in the url of genome browser page were going to be completely opaque to the client; but we have now recognized that we want the client to know which type of feature it is dealing with in order to be able to correctly format requests to the api; and for doing so, it should parse feature ids. Therefore, there is no need for a backend endpoint that returns to the client a parsed ens-object if the focus object happens to be a region.

Client-side concerns

Todo (later):

  • Probably rename ens-objects to focus objects
  • Move focus objects to genome browser part of redux state; we will not reuse them in other applications, because other applications will need different subsets of data regarding focus objects
  • Probably separate different types of focus objects into their own namespaces, because the shapes of the focus objects will be different depending on what type they are:
focusObjects: {
  genes: {
    [key]: FocusGene
  },
  regions: {
    [key]: FocusRegion
  }
}

Note 1: the keys for storing focus objects in the structure above will have to include genome id, because the stable id of a feature is not sufficient to discriminate between different assemblies (e.g. both grch37 and grch38 may have genes with the same ENSG...). Note 2: don't know whether there is any value to having regions in the focusObjects state at all; their data is just the location of the region, which can be encoded in their ids Note 3: what we call regions in genome browser, the core api will call slice — I wonder if this will cause us headache Note 4: check how this is going to work with with bookmarks

Clone this wiki locally