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
{{ message }}
This repository has been archived by the owner on Jun 21, 2024. It is now read-only.
I'm considering adding a Hydrate method to all of our types (or ServiceOps) which could be used as a Hydratable interface and would allow for objects with only an Href to have their Href parsed and have Get called on the object. Each type may also need an Href getter to implement this, I'm not sure yet.
This would likely result in a refactor of Get to rely on Hydration.
obj.Hydrate() could also be used to refresh an existing object, which is something that we do sometimes in integrations. Hydrate might need to take include/exclude parameters, and define the default inclusion parameters for each object type.
Our types don't have client references, and should not need to care about clients. The Hydrate method would likely be a part of the FooServiceOp type.
I'm considering adding a
Hydrate
method to all of our types (or ServiceOps) which could be used as aHydratable
interface and would allow for objects with only anHref
to have their Href parsed and haveGet
called on the object. Each type may also need anHref
getter to implement this, I'm not sure yet.This would likely result in a refactor of
Get
to rely on Hydration.obj.Hydrate()
could also be used to refresh an existing object, which is something that we do sometimes in integrations. Hydrate might need to take include/exclude parameters, and define the default inclusion parameters for each object type.Our types don't have client references, and should not need to care about clients. The Hydrate method would likely be a part of the FooServiceOp type.
This may just be a bad idea 😄
Originally posted by @displague in #242 (comment)
The text was updated successfully, but these errors were encountered: