Core refactor

[bhousel]

Opening a PR here for visibility, but I'm ready to merge the last month's work that reorganizes and modernizes most of the core components of Rapid to make things a lot easier to work with, and hopefully eliminate a lot of the "magic" in the project that was making startup complicated and reduce the amount of spaghetti code.

I'm drawing inspiration from how Pixi.js organizes their core components into "systems" owned by a "renderer".
In Rapid, our "systems" will continue to be owned by our "context" object.

The deets:

• Core components are now "systems". Each system has one job.
• All code is now written in modern ES6+ style Javascript using classes.
• No more globals (singletons, whatever we called them). Everything must be accessed through Context.
• Each component has a constructor that receives the Context. Constructors may not use things from other components.
• Each component has dedicated init and reset methods. We had these before but we're making it more clear now. Init is when you can start referring to things in other components. (We should make the inits async).
• All these components use EventEmitter to emit events - no more d3-dispatch/d3-rebind
• Trying to avoid the old d3-style setter/getter methods in favor of just using ES6 class properties.
• The naming of a lot of things has changed for consistency and clarity.
  • prefer ThingCategory (e.g. MoveMode or MapillaryService or ValidationSystem)
• A few legacy components got updated to ES6 classes - we didn't have time to get these in before the v2 launch.
• These rules apply to everything in core of Rapid.. Modes, Behaviors, Services, Systems.
• Components can be replaced before calling Context.init - so if someone really wanted to replace a core component with their own, it's now possible.

todo:

• Some more things should be systems:
  • The scene graph should maybe a system. It's currently owned by the PixiRenderer. But other parts of the code talk to it to know what layers are enabled, what things are selected or hovered, etc. It might need a new name too.
  • utilKeybinding() should be KeyboardSystem or something. (Different parts of the code should not be responsible for their keyboard shortcuts, and this would be a first step towards letting users remap their keyboard shortcuts).
  • We need a SchedulerSystem - we are currently using the Pixi.Ticker event loop now, but we also sometimes need to schedule background work, and Rapid performs poorly on Safari because of the polyfill for RequestIdleCallback. Also should start moving things to web workers.
  • I'd like a proper DatabaseSystem that wraps IndexedDB and is useful for larger amounts of data that can be accessed async and in workers. We're currently abusing the StorageSystem (wraps localStorage) to store the user's edit history and it has hit its limits.
• Validators are still mostly function modules, we will modernize these as time permits, and with an eye for getting them running in workers.
• Some consideration needs to be made for which parts of Rapid are still OSM-only and how to make things more generic. For example many of our third party datasets (like the roads or buildings) work by making fake OSM features, and we still have different modes like SelectThing and SelectOSMThing - We can't select multiple things at the same time, and this is blocking us from shipping cool features like "merge data from dataset into OSM". (This is just one example of how the the OSM-focus of the old architecture limits us). Of the top of my head, the sidebar, the info panels, etc needs to be updated.
• Really the whole UI needs a refresh. They are mostly still d3-style function components
• Init is still not a solved problem. All init methods could probably be async so components can depend on other components cleanly.
• Documentation. I've done so much, but there's so much more to do 😅