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.
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
andgetConflicts
so that they don't need a special variants for each entity type, likegetLogLastChange
andgetAssetLastChange
. This could be achieved by using constructors for each entity type, like this: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'sid
, which is how the log should be structured for sending to the farmOS server ultimately, but when the consumer callsmyLog.assets[0]
they get the asset itself, and so can also callmyLog.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
andfarm.connect
, but we could wrap them up into a generalfarm
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.