openownership
Split up data parsing, modelling and rendering better
Moving this from the initial code review in #17. Currently we mix these concerns a little, but as we grow the app we'll need to refactor things so that we have a clear data parsing step, models for nodes/edges derived from BODS data and rendering code, all in their own places and wired together into the UI. This should probably be accompanied by some unit tests and an overall test of the library using something like jsdom.
See https://github.com/openownership/visualisation-tool/pull/17#discussion_r425676892 for an example of something that could be potentially cleaned up whilst refactoring.
As discussed with @kd-ods today, architecturally, it may be necessary to make breaking changes to the usage of this tool. The next version may involve calling a different method, or even multiple methods, rather than the current draw() method due to splitting things out.
I'm largely brainstorming at this stage, so changes to the usage may not be as significant as I'm picturing, and efforts will certainly be made to Keep It Short and Simple (KISS) and as similar to current usage as possible.
