Expect msg is an opaque type and has a type parameter msg. There are situations when a mapExpect function can be useful to map a message produced by expect. In fact such function is implemented already in kernel module.
At the moment Http module exposes functions to transform requests to Cmd msg and Task x a. Both of the types expose map function. However it's a higher level abstraction on top of Http request. Once you converted Http request to command or task there is no way to go back.
On the other side it seems very harmless to expose mapExpect function to provide lower level manipulations with Http requests.
Alternative solution is to build own abstraction around Http request and transform it to a request with Expect msg at the very end.
My situation where it's useful.
(1) Let's say each request has some common logic around it. If the user is authenticated we send a request header with an authentication token to the server. Let's say we send few more common headers to the server.
One way to handle it is to drill the token and other common data to every place we'd like to make an Http request.
Another way is to make a middleware between Elm runtime and the place where we make an Http request so that all common headers added for each request.
(2) On each response from server we would like to do some common stuff. E.g. server invalidates a token and we want to logout the user. Or the server returns it's current time, so that we want to sync client time with server time, etc... The point is that there is a common logic for each response from the server.
Hi.
Expect msgis an opaque type and has a type parametermsg. There are situations when amapExpectfunction can be useful to map a message produced by expect. In fact such function is implemented already in kernel module.At the moment
Httpmodule exposes functions to transform requests toCmd msgandTask x a. Both of the types exposemapfunction. However it's a higher level abstraction on top of Http request. Once you converted Http request to command or task there is no way to go back.On the other side it seems very harmless to expose
mapExpectfunction to provide lower level manipulations with Http requests.Alternative solution is to build own abstraction around Http request and transform it to a request with
Expect msgat the very end.My situation where it's useful.
(1) Let's say each request has some common logic around it. If the user is authenticated we send a request header with an authentication token to the server. Let's say we send few more common headers to the server.
One way to handle it is to drill the token and other common data to every place we'd like to make an Http request.
Another way is to make a middleware between Elm runtime and the place where we make an Http request so that all common headers added for each request.
(2) On each response from server we would like to do some common stuff. E.g. server invalidates a token and we want to logout the user. Or the server returns it's current time, so that we want to sync client time with server time, etc... The point is that there is a common logic for each response from the server.