farmOS / field-kit

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

Extend farmLog to handle assets and other entities #401

Closed jgaehring closed 3 years ago

jgaehring commented 3 years ago

I'm starting to think about how we can extend the farmLog factory function to other farmOS entities like assets, areas, taxonomy terms, etc.

One thing that I think will be important is introducing a degree of polymorphism for functions like getLastChange and getConflicts so that they don't need a special variants for each entity type, like getLogLastChange and getAssetLastChange. This could be achieved by using constructors for each entity type, like this:

function Log() { return this; }

// Then in createLog...
const log = new Log();

// ... instead of:
const log = {};

// Then in getLastChange and other functions we can check which entity we're handling:
if (entity instanceof Log) {
  // then do things specific to logs, particularly regarding the logs' symbol registry
}

Another interesting possibility is using ES6 Proxies to model relationships between entities, as I briefly mentioned in https://github.com/farmOS/farmOS-client/issues/358#issuecomment-679295369. Basically this means we could structure our logs' assets property as an entity reference using the asset's id, which is how the log should be structured for sending to the farmOS server ultimately, but when the consumer calls myLog.assets[0] they get the asset itself, and so can also call myLog.assets[0].location.name to get the name of that asset's location.

One last idea: it would be great if farmOS.js would eventually become a repository for both these entity factories and the networking library. We could still make it possible to pull each as an independent library, say as farm.data and farm.connect, but we could wrap them up into a general farm library that provides some general integrations and serves as a full package farm client, that any application could build their own UI on top of.

Obviously we have a long way to go before then, and there will be a lot more details in simply implementing factories for all the entities, but these are just a few ideas floating around my head right now.

jgaehring commented 3 years ago

On the 2.x branch I've generalized the basic create/merge/serialize/deserialize methods for all entities, so this can be closed.