Front-end refactor master issue

[ostermanj]

This issue refers to front-end refactoring tasks to improve performance of the app and maintainability of the codebase that will not affect the UI or features.

Three main aims, as I see them.

1. Identify and fix any runtime errors the app may be (is) throwing on the client side.
2. Simplify, streamline, and reduce repetition of the JavaScript codebase so that it's easier to maintain and more attractive to work on.
3. Speed up the page load: better sequencing and potentially deferring some data downloads until requested by user.

Another question, not quite in the scope of this, is whether the front end should eventually be built on an established platform, React or Vue.js for instance. If we do eventually go that way, a refactor of the existing framework-less codebase should make that easier.

Identify and fix runtime errors (tasks to be added and modified; issue numbers to be added)

• [ ] Set up Rollbar.js error tracking so we know what errors are being thrown, in addition to what we know from our own testing (#615)
• [ ] Fix any easy ones; more difficult issues may need to be fixed during subsequent steps of the refactor

Simplify, streamline, and reduce repetition

• [ ] Set up a dev environment / task runner (I'm most familiar with Grunt) so we can take advantage of some automatic tasks (like code linters and build processes) and ES6+ syntax and APIs.
• [ ] Set up an html linter; find errors in the html files and fix them.
• [ ] Set up a JavaScript linter; find errors in the .js files and fix them.
• [ ] Set up an CSS preprocessor so we can can write in SCSS instead of CSS and make easy use of variables, mixins, etc, in our stylesheets. This is less and less crucial as CSS itself improves, but preprocessing still makes sense because of variable browser support for new CSS features and because only preprocessing allows us to write nested CSS.
• [ ] Set up Babel or other ES6 transpiler so that we can use ES6+ syntax and have it translated into pre-ES6 code. We need to support older browsers (likely a lot of people on IE11 in Windows 7) and so can't rely on native support of up-to-date JavaScript, but it's bothersome to restrain ourselves from using it.
• [ ] Refactor code into ES6 syntax and methods where there's advantage to doing so. Promises will be super helpful since we're dealing with asynchronous data requests, and they'll give us more control over what's now cumbersome callback confusion. I haven't ventured into async/await methods but they may also be super helpful. Arrow functions especially help streamline D3 code by giving easier way to bind the context (the this).
• [ ] Keep source files separate but combine into one build file by using import and require. One master .js file could have nothing but the imports and requires of all the others plus the code to initialize the app. The ES6 transpiler allows us to use the syntax. We import components of one .js file into another. We keep our files organized by component but avoid having to link to so many files on load. The build process puts them all together.
• [ ] Standardize code styles and methods. For instance, we have a mix now of d3 selections, jQuery, and native querySelector(All). Should we enforce one? Can we get rid of jQuery (sematic UI depends on it).

Speed up the page load

• [ ] Refactoring the data requests and dataCollection into Promises, perhaps with async/await should help speed things up.
• [ ] Troubleshoot the page load sequence and make changes where necessary
• [ ] Consider loading less data on load and make API calls later in response to user action.