Closed jgaehring closed 2 years ago
I'm thinking now it might make most sense to nest everything except Vue
and app
under the lib
namespace. So:
window.lib.R = ramda;
window.lib.wellknown = wellknown;
window.lib.geometry = geometry;
window.lib.parseNotes = parseNotes;
window.lib.useEntities = useEntities;
// etc...
Overall, this seems like it would reduce the mental overhead of additional namespaces, while keeping it all relatively safe from collisions.
That last one, useEntities
, is a Vue "composable", analogous to React hooks, and at the moment I'm leaning most heavily towards this approach to scoping the checkout
/revise
/commit
functions (#494), which is what useEntities
would return.
There's also the question of vue-router
's composables, like useRouter
. I could monkey patch the Vue
object, but that seems risky. It might also be acceptable to make one more exception to the "everything under lib
" rule, and just create a separate window.router
namespace, since it's a rather extensive library and is critical to working with module components.
At this point all the global objects bear rethinking since so much has changed.
First of all, I want to get rid of the
farmOS
global object. This was necessitated by farmOS-map 1.x, but is no longer a requirement for farmOS-map 2.x, AFAIK. This frees up more possibilities for how other globals are structured.One thing I don't really have much choice on, though, is the
Vue
constructor, which must be exposed directly on the globalwindow
object. With that the case, it makes sense to put the main Vue instance,app
, directly onwindow
as well.Apart from that, I'd like to settle on 3 main top-level namespaces, which all other globals will be nested under:
window.farm
window.lib
window.utils
farm
will be analogous to farmOS.js, though not exactly the same (more on that in a follow up issue).lib
will be for third-party libraries, like Ramda andwellknown
. And of courseutils
will be for utilities, likegeometry
andparseNotes
etc.