API Layering (not map layers)

[james-rae]

This is mostly from discussion between @AleksueiR and @spencerwahl

After some debate, to get the most benefit out of Vue/VueX it looks like we need 2 layers to the API. One layer for Vue code, and one layer for any other Javascript.

Vue

• VueX store interactions designed to be API wherever possible
  • We can have an unlimited number of stores, one store for each domain of interaction? (layers, legend, etc.)
  • There may be some "private" internal stores needed; functions that aren't useful in anyway for things outside of core
• For interactions that don't go through the VueX store we have a Component(?)/Class(?)/something with all of those functions

This allows anything Vue to interact with the stores directly, whether its the base modules or something someone else writes. As I understand it, the new Vue code only needs to be able to register with the same Vue instance as R4MP.
The non VueX store object keeps Vue code from having to use the global scope, makes using types easier and keeps the code cleaner.

Other

API to be placed on global scope (window.RAMP or whatever we choose to name it this time).

• Vuex store functions get wrapped
  • Functions on top of actions. These functions do nothing but call the store function with the same arguments they received.
  • Observable on top of getters. When the data bound to the getter updates, push the updated data into the observable.
• Other interaction functions get copied over

This gives a nice interface for non-Vue code, the only things that really change are observables instead of binding and a different prefix for the functions (adding window.RAMP.... in front)

[james-rae]

Resolved by having InstanceAPI and using window.RAMP to make new instances. Vue store is exposed via instance but standard interactions are done via API calls, not direct store manipulation.