-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Addition of a Request "send" #62
Comments
So
What is your reason for wanting it? |
send : (Result Rest.Error a -> msg) -> Rest.Request a -> Cmd msg as opposed what you @russelldavies wrote above: send : (Result Http.Error a -> msg) -> Http.Request a -> Cmd msg the difference being My reason for wanting to add it is to make the API closer to that of HTTP + have a nice and easy taskless way to send things. We'd still have a |
Ah okay, that makes sense. And you mentioned the lower level functions so all good (as I often use Anyway, I prefer option 3. It is the least cumbersome and most flexible because you can change request options at the last moment. Option 2 with reversed parameter order is also ok as you can then curry it. |
As a point of reference, this is what I've done to accommodate the new API changes in Http v2: httpRequest : { baseUrl : String, token : Maybe String, toMsg : Result Http.Error a -> msg, timeout : Maybe Float } -> Request msg a -> Cmd msg
httpTask : { baseUrl : String, token : Maybe String, timeout : Maybe Float } -> Request msg a -> Task Http.Error a |
The essence of this change is that I'd like to have a function with the same API as Http.send from elm/http:
https://package.elm-lang.org/packages/elm/http/latest/Http#send
Right now, this is not possible because the URL (among other options) is not a part of the
Rest.Request a
value. In the APIs current state, we pass those options via thetoHttpRequest
function:My idea is to pass these options as a part of each CRUD function, like so:
or
As an alternative solution, we could just pass these options to the proposed
send
function, like so:I'm not yet sure what makes the most sense, however, I wanted to document some thoughts.
Things like: the order of the options, whether it's a record, if we provide a "default" value, etc all depend on how/where people are using these functions + what things are likely to be partially applied.
The text was updated successfully, but these errors were encountered: