For a long time now we've been using Vue Router's named views to embed custom menubars (aka, "app bar," in Material parlance) for each route, but this adds a lot of unnecessary complexity, particularly when the menubars need access to global state and event emitters for manipulating that state, or just plain navigation. It's also tightly coupled with the FarmMenubar component, requiring field modules explicitly use that component (and its slots) in a very prescribed manner, which altogether seems quite brittle and prone to regressions in the future, unless we totally lock-down FarmMenubar and never change it.
Maybe there's a way we could build this out incrementally, if we start out by making the sync process something that is controlled by FK core, instead of the Tasks module, and move any buttons for the user to manually sync to the core UI. This could be done in the app bar, the drawer, the home page, its own "settings" or "records manager" page, or in several of those places at once. And we could start small, both in terms of manual syncing and automatic syncing.
In general, as we near the first release of the Field Module API, it would be prudent to limit that API surface as much as possible, and the menubar seems like a prime target for reducing that surface.
I'm not entirely sure how best to go about this, because I still would want modules to be able to add some functionality to the app bar, but hopefully something declarative, that could be represented as a relatively simple JavaScript object, or array of objects. So the TasksEditMenuBar, for instance, might be represented as:
const appBarOptions = [
{
text: 'Open in browser',
button: 'icon-open-in-new',
onClick() {
// do something...
},
},
{
text: 'Delete from device',
button: 'icon-delete',
onClick() {
// do something...
},
},
{
text: 'Sync this log',
button: 'icon-cloud-upload',
onClick() {
// do something...
},
},
];
Although, like I said, this will hopefully go hand-in-hand with increased restrictions on what field modules can do in terms of deleting and syncing data, so some of those options might not be included.
For a long time now we've been using Vue Router's named views to embed custom menubars (aka, "app bar," in Material parlance) for each route, but this adds a lot of unnecessary complexity, particularly when the menubars need access to global state and event emitters for manipulating that state, or just plain navigation. It's also tightly coupled with the
FarmMenubarcomponent, requiring field modules explicitly use that component (and its slots) in a very prescribed manner, which altogether seems quite brittle and prone to regressions in the future, unless we totally lock-downFarmMenubarand never change it.Another consideration is what I proposed in https://github.com/farmOS/farmOS-client/issues/274#issuecomment-1008078831, regarding automatic syncing and restricting field modules' control of the syncing process in general:
In general, as we near the first release of the Field Module API, it would be prudent to limit that API surface as much as possible, and the menubar seems like a prime target for reducing that surface.
I'm not entirely sure how best to go about this, because I still would want modules to be able to add some functionality to the app bar, but hopefully something declarative, that could be represented as a relatively simple JavaScript object, or array of objects. So the
TasksEditMenuBar, for instance, might be represented as:Although, like I said, this will hopefully go hand-in-hand with increased restrictions on what field modules can do in terms of deleting and syncing data, so some of those options might not be included.