Something I've realized with the addition of the useSubrequests pattern I introduced with #68 is that it would actually be kind of nice to implement some kind of plugin architecture for more niche features like that, but also as a way to make even standard methods like .fetch() and .merge() a little more modular for core development.
I've noticed a bit of a pattern emerging in both the model and client methods where either the request or schemata instance must be injected as dependencies to return the final method, as below.
That's OK, but I feel like it could be prudent to try to standardize on some like of .use() method that could be used internally to attach these methods, and then if it works well, eventually exposing it as a part of the API.
There may also be some lessons in the way we parameterized the auth mixin, and hopefully it would eliminate some of the yuckier patterns I've been falling into, like this entityMethods helper:
None of this is necessarily required for the 2.0.0 general release, but it could be nice to establish this prior to that, so I'm including it in that milestone for consideration.
Something I've realized with the addition of the
useSubrequestspattern I introduced with #68 is that it would actually be kind of nice to implement some kind of plugin architecture for more niche features like that, but also as a way to make even standard methods like.fetch()and.merge()a little more modular for core development.I've noticed a bit of a pattern emerging in both the
modelandclientmethods where either therequestorschematainstance must be injected as dependencies to return the final method, as below.https://github.com/farmOS/farmOS.js/blob/0d54425db537bd5e1d2d7433bfb9d81eabc76bea/src/client/send.js#L14-L28
https://github.com/farmOS/farmOS.js/blob/0d54425db537bd5e1d2d7433bfb9d81eabc76bea/src/model/update.js#L20-L60
That's OK, but I feel like it could be prudent to try to standardize on some like of
.use()method that could be used internally to attach these methods, and then if it works well, eventually exposing it as a part of the API.There may also be some lessons in the way we parameterized the auth mixin, and hopefully it would eliminate some of the yuckier patterns I've been falling into, like this
entityMethodshelper:https://github.com/farmOS/farmOS.js/blob/0d54425db537bd5e1d2d7433bfb9d81eabc76bea/src/client/adapter/index.js#L112-L140
None of this is necessarily required for the 2.0.0 general release, but it could be nice to establish this prior to that, so I'm including it in that milestone for consideration.