farmOS / field-kit

A modular, offline-first companion app to farmOS.
https://farmOS.org
GNU General Public License v3.0
59 stars 38 forks source link

Reorganize global namespaces #493

Closed jgaehring closed 2 years ago

jgaehring commented 2 years ago

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 global window object. With that the case, it makes sense to put the main Vue instance, app, directly on window as well.

Apart from that, I'd like to settle on 3 main top-level namespaces, which all other globals will be nested under:

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 and wellknown. And of course utils will be for utilities, like geometry and parseNotes etc.

jgaehring commented 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.