Closed amitaibu closed 6 years ago
You can use patch
or patchAny
to cover that case.
patch
, you'd supply a MyAccount -> Value
function (along with the MyAccount
)patchAny
, you'd supply some arbitrary Value
Now, we could simplify the type signature for patch
if we allowed only one patch type (so that it was in the config itself). However, I think it will sometimes be the case that we want to patch in several different kinds of ways -- for instance, we might send just one field in one case, and just another field in another case. So, I think it's probably best to delay specifying the patch type to when we actually call patch
, rather than putting it in the config.
(The exception is patchFull
, since in that case we have the encoder in the config anyway).
Makes sense, thanks!
I have a My account page that I'd like a user to be able to update.
type alias MyAccount
holds some properties that can be related to thetype alias User
, but it's only a subset and some fields and some are not in the User at all (e.g. apassword
field, which a user may update).So, my case is
PATCH
aMyAccount
and get a result of aUser
. If that would have been a create operation I could have:endpoint : ReadWriteEndPoint Http.Error UserId User MyAccount ()
Maybe we should expose also the Patch type in the signature?