If a web worker is not responding, terminate it, start a new one, and add it to the pool.

Probably want to just add a ping() rpc method to render.worker.js and call it from the main thread at some interval

The regularizing sequence names in JBrowse 1 is done via regex, we probably want to be more explicit, and could also regularize assembly names

@rbuels I decided to not actually do any configs for the track selector until the stuff you're working on now gets merged.

I was just planning to do some simple configs to have categories be expanded or collapsed by default. We could probably do a category and track sorting config sometime too, but not sure if we want to add that quite yet.

a linear genome view should be able to export its currently visible stuff to an svg file

this will include putting any visible canvas tracks into svg images in the export

I think generate-names is probably the only major part of the Perl codebase we're going to be wanting to carry into JBrowse 2, so we should probably port it to node for 2.0.

We would keep the Perl version of it in JBrowse 1 of course.

depends on #55

Since we want basically everything to be configurable, we're going to need a way to load things like plugins from user-defined sources. With dynamic imports, we can at least load custom React components, which is a good start.

Need to experiment and see if this will work well for us.

We are currently, as of this moment, using 0-based coordinates. JBrowse 1 is 1-based

This is pretty much done in 1b21900, just needs some tests. The drawer defaults to 25% of the window width, and the tracks automatically fill up the remaining space. The drawer can be dragged to resize it, and when the window is resized it tries to keep the drawer approximately the same proportion of the window width.

Possible idea: having an option where the drawer is disabled, but can still be temporarily rendered as some sort of pop-over in response to something like the "select tracks" button being clicked.

Right now if you do a production build and run it, the service worker throws an exception:

If we want to use service workers, we'll have to figure out what's going on here.

We intend to make a CLI for doing some data loading steps and probably name indexing

Currently in master when running yarn build the build folder doesn't actually get populated with an js files.

This is going to have a bunch of highly inter-related components in it, so we probably should make it a monorepo.

using Lerna maybe. or just some little scripts.

includes:

• appropriate directory structure
• travis build for each component that runs its tests

will do deployments later

first little linear view will just take some input of how things should be rendered, and render it. no mouse events or anything yet.

input:

• track configuration for every track that should be displayed. all tracks in the input will be displayed (track selection is handled above this level)
• the reference sequences and ranges that should be displayed. these will be laid out end to end.
• metadata about how it should be displayed
  • the zoom level: base pairs per pixel
  • scale number bar configuration (on or off, maybe hints about scale frequency)

output:

• react rendering of the requested ranges laid out horizontally, and a column of track names on the left side

Nested class definitions? Collisions are not even important in this model so might not be needed, also use BEM?

@garrettjstevens are more accessible with CSS-in-JS

Takes a structure of just track names and ids, and the categories they go under, and make a react implementation of the hierarchical track selector, pretty much exactly like JBrowse 1.

Upgrade dependencies to match create-react-app v2.0.3. Document how this was done so we can pull in future updates.

Could be good to set up Greenkeeper or something like it to help us keep deps up-to-date.

Lint warnings cause an error to be throw for production builds that run under CI. Need to clean up our warnings so the build can work properly.

http://dagchainer.sourceforge.net/

You can see the output file looks like this

1       At1g01010       3760    5630    1       At1g02230       436775  433031  1.3e-45
1       At1g01010       3760    5630    1       At1g02250       439559  437951  1.5e-37
1       At1g01010       3760    5630    3       At3g04420       1172846 1174301 1.9e-33
1       At1g01010       3760    5630    4       At4g01520       659178  656407  5.6e-34
1       At1g01010       3760    5630    4       At4g01540       672629  670483  2.8e-36
1       At1g01010       3760    5630    4       At4g01550       676225  674025  1.5e-44
1       At1g01020       8666    7729    4       At4g01510       642683  644190  2.6e-33
1       At1g01030       12940   11864   2       At2g36080       15158490        15155691        1.2e-39
1       At1g01030       12940   11864   2       At2g46870       19268382        19269314        6.2e-56

This is sort of a "2D" data format and if we need to query in 2D format it might be worth looking at something like pairix? https://github.com/4dn-dcic/pairix Or some other format. Could also parse entire file client side if it is small enough

Need a parser for trackDb.txt files in order to be able to connect to track hubs. It's probably complex enough that we'll want to put it in its own NPM module. We'll see once it's written.

Make a mult-level view can show 2 or more zoom levels simultaneously, linking them with polygons, and drawing tracks on any of them. Could do this by having several "child" LGVs (with overviews turned off), or by just implementing a multi-level view from scratch.

====|=|=========
   /   \
=|===========|==
 /            \
===============

Rob's off-the-cuff guess is that implementing from scratch would be the easiest and get the best results.

One of the last remaining core data types that we need a npm module for :)

Scrolling side to side on the BAM track produces repeated errors of this type

Uncaught Error: [mobx-state-tree][error] You are trying to read or write to an object that is no longer part of a state tree. (Object type was 'BlockState'). Either detach nodes first, or don't use objects after removing / replacing them in the tree.
    at ObjectNode$$1.assertAlive (mobx-state-tree.module.js:1576)
    at ObservableValue$$1.ObjectNode$$1._this.unbox [as dehancer] (mobx-state-tree.module.js:1359)
    at ObservableValue$$1.dehanceValue (mobx.module.js:762)
    at ObservableValue$$1.get (mobx.module.js:822)
    at ObservableObjectAdministration$$1.read (mobx.module.js:3936)
    at Object.get [as key] (mobx.module.js:4199)

This will be easy if KyleAMathews/typefaces#92 gets accepted sometime soon, but otherwise we'll have to do manually like in https://google.github.io/material-design-icons/#setup-method-2-self-hosting.

Add a button to export the current configuration to a downloadable file.

@cmdcolin, @rbuels, working with UCSC tracks and then playing with Rob's graphical config editor, I've started to wonder what we want JB2 to have with regards to subtracks. I know we mentioned it in the planning session back in Sept, but I don't remember what we decided.

One feature I can think of that would be useful is to use subtracks to apply settings to a bunch of tracks at once. For example, the parent track would basically just be a "folder" to put other tracks in, and any configs applied to the parent track would apply to all the subtracks.

What else do we want to be able to do with subtracks?

when you hit the 'configure' button on something, that button stays down/active, and a configuration editor for that thing pops up in the side drawer.

configuration edits are validated as they are input, and if they are valid, they take effect immediately upon typing

Would be good to enable something like codecov. Probably don't need to focus on getting really high coverage right now while everything is new, but would be a good reminder to keep writing tests.

This is complicated by the fact that the canvas API is not available for worker-side rendering.

Can possibly try https://github.com/casperlamboo/canvas-webworker#readme, or try porting the remote canvas rendering stuff that I implemented in the old 2.x branch

flowAnimator in the rbuels_junk branch has the beginnings of this: https://github.com/GMOD/jbrowse-components/compare/rbuels_junk?expand=1#diff-c6daf6500d7e92631a04b09422fde771

Basically I envision an MST model that has a current value, a stiffness, and a damping, and is updated with some kind of flow action that will animate the current value to the new target.

Basically an MST version of https://github.com/chenglou/react-motion

"Remote" tracks will be those on a server, connected hub, etc. They'll be "static" in the sense that you won't be able to edit the configurations, but there will be an easy way to copy them over to your own tracks, and the copy can be edited and saved freely.

input: a request for a range, output: a rendering of the features in the range, and also the feature data itself

a render request contains:

• the reference sequence and range to render
• all relevant configuration for how it should be rendered, including URLs for the data, etc

the response contains:

• the rendering of the range
• appropriate metadata about the rendering (is it svg or canvas, what are its pixel dimensions, etc)
• the feature data itself (may be needed by the frontend for doing .... whatever)

should develop this in a way that the request and response could actually go from and to anywhere, so this could run in a web worker, or on the server side in an expressjs app

so that jb2 will work in browsers that don't have OffscreenCanvas

takes a data structure of menu names and the callbacks to be executed for each, just returns a <div> that's appropriate for sticking at the top of an app.

should probably be implemented with some off-the-shelf react menu bar.

Currently workerPolyfill.js works for the dev builds, but not for prod since it uses a different library (mini-css-extract-plugin). Need to try to get that working.

mini-css-extract-plugin and worker-loader both run as child compilers, and create-react-app doesn't handle errors in child compilers all that well.

Intended to be in top right corner of the linear genome view as per mockup

Basically we just want to inform users if their browser is unsupported either by browser or feature detection

@rbuels I think I'm trying to use readConfObject() correctly, but let me know if I'm not. I can do this just fine:

readConfObject(MODEL.configuration.tracks[0], 'name')
// "volvox-sorted red/blue"

but this doesn't seem to work:

readConfObject(MODEL.configuration.tracks[0], 'category')
// Proxy {0: ScalarNode$$1, 1: ScalarNode$$1, length: 2, $treenode: ObjectNode$$1, toJSON: ƒ, Symbol(mobx administration): ObservableArrayAdministration}

If you do a getSnapshot() it works, though:

getSnapshot(readConfObject(MODEL.configuration.tracks[0], 'category'))
// ["Bar Category", "Baz Category"]

I've tried to start fixing it, but got a bit confused and thought I'd let you know in case you have a quick solution.

scope of this issue has changed to just be the "share" UI.

"file -> share session" will pop up a drawer widget or popup with sharing options.

===============================================

Given that there can be more than just a simple location for example in a given view, a more complex session might need encoding

The simplistic &data= and &loc= URL navigation has been quite valuable in the past and would be worth preserving in some type of way too (moved to #348)

All the plugins developed so far have been core plugins, so I decided to create and test a simple non-core menu bar for testing before I create the core Main Menu Bar.

I also added a Yeoman generator to generate this testing menu bar. It's working now in 9022ca0 if you follow these steps:

1. cd into the jbrowse-web plugins dir
2. run yo jbrowse and follow the prompts
   
3. add a few lines to the main index.js

...
import HelloWorldMenuBar from './plugins/HelloWorldMenuBar'
...
jbrowse.pluginManager.addPlugin(new HelloWorldMenuBar())
...
model.addMenuBar('HelloWorldMenuBar')
...

4. yarn start
   

It would be good to have an integration test that basically does what I showed in the steps above.

make a drawer widget that:

• lists data hubs that we currently know about, with a check box showing whether they are "connected"
• has a UI to add a data hub
• persists the list of hubs in local storage
• when a data hub is connected, adds its assemblies and tracks to the configuration (root.configuration.tracks, etc) so that the tracks are available in the track selector