You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
andclient
methods where either therequest
orschemata
instance must be injected as dependencies to return the final method, as below.farmOS.js/src/client/send.js
Lines 14 to 28 in 0d54425
farmOS.js/src/model/update.js
Lines 20 to 60 in 0d54425
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:farmOS.js/src/client/adapter/index.js
Lines 112 to 140 in 0d54425
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.
The text was updated successfully, but these errors were encountered: