search

farmOS / farmOS.js

A JavaScript library for working with farmOS data structures and interacting with farmOS servers.
MIT License
15 stars 13 forks source link

Flatten resource objects in relationships #38

Closed jgaehring closed 2 years ago

jgaehring commented 3 years ago

In Field Kit it's kind of a pain that the relationships fields are carrying over all the properties from JSON:API (eg, links), when really all I need in FK are the id and (possibly) type fields under data. I want to think carefully about how this could be flattened in the model, particularly with regards to #34, but some degree of pruning seems like a good idea.

mstenta commented 3 years ago

I suppose the question is: will a Field Module ever want to follow those links for any reason?

jgaehring commented 3 years ago

Hopefully not. I really want to dissuade Field Modules from making independent requests to the server that don't go through Field Kit's fetch/sync API.

mstenta commented 3 years ago

Makes sense. Perhaps "dissuading" can be done by providing good options, rather than removing them, though. Encourage the use of higher-level APIs, but still allow lower-level ones for maximum flexibility. Maybe that's already happening in this case, and it would still be possible to make requests outside of the fetch/sync API. Just thinking: if someone is blocked because Field Kit's APIs don't support something, even though farmOS does, that would be frustrating.

I might be over-generalizing here. Just thinking out loud. :-)

jgaehring commented 3 years ago

Oh yea that's definitely the case here. Field Modules still have all the power of JavaScript to launch the missiles or make any API call to any server they wish. As I think I've said before, there's nothing preventing module developers from writing a Hacker News clone if they wish. I'm just trying to make the ergonomics as clean and easy as possible that they won't want to, in favor FK's own API. That way they won't be tempted to use that link property, when all they need to do is pass the id into the appropriate sync method. By making that id easier to access, they will hopefully be more inclined to use the syncing API, and by so doing, avoid introducing concurrency bugs that they would otherwise be prone to.

mstenta commented 3 years ago

Makes sense! Sorry didn't mean to distract from the issue at hand. :-)

jgaehring commented 2 years ago

Resolved by 9019f6f