This gives me (|>) is expecting the right side to be a: Task.Task Http.Error MyType -> a But > the right side is: Http.Request (Maybe MyType) -> Cmd Msg
but maybe this is an artefact of old 0.17 architecture where I was too defensive for the case if reading JSON fails. Sorry for trowing just an exception message but I'm really not sure how to proceed here. :( And thank you for all your support so far. On Wednesday, November 16, 2016 at 8:25:23 PM UTC+1, Peter Damoc wrote: > > > On Wed, Nov 16, 2016 at 8:19 PM, Tim Bezhashvyly <[email protected] > <javascript:>> wrote: > >> You mean something like: >> >> triggerReadingFromJson = >> Http.toTask (Http.get "my.json" decoder) >> |> Task.andThen (\result -> Task.succeed result) >> |> Task.onError (\error -> Task.fail error) >> >> Task.andThen is used when you need to chain multiple requests like > asking for some info from one endpoint and using the information received > to make another call to a different endpoint based on the received info and > encapsulate that into one, single, request so you get only one message. > > For what it looks like you try to accomplish, you just need to create the > Request and use Http.send to convert it into a Cmd (the command that sends > the request to the server) > > triggerReadingFromJson = > Http.get myJsonUrl decoder > |> Http.send (Result.Extra.unpack FailMessage SuccessMessage) > > I've used the helper suggested by Janis so you need to > install elm-community/result-extra and add it to your dependencies. :) > > > > > >> But in this case the result is "Task.Task Http.Error MyType". What can I >> do with it? I need somehow cast it to either MyType or Cmd, right? >> >> >> On Wednesday, November 16, 2016 at 3:23:13 PM UTC+1, Peter Damoc wrote: >> >>> On Wed, Nov 16, 2016 at 4:05 PM, Tim Bezhashvyly <[email protected]> >>> wrote: >>> >>>> Chained to Task.andThen and Task.onError? And what those tow must >>>> return? I assume commands as they can't change model directly, right? >>>> >>> >>> Chained with Task.andThen ;) >>> >>> As for the return type, I would return success and fail data and only at >>> the last stage map it onto the message creators. >>> The command is the equivalent of the Task in that it is a request for >>> some side effects. It is not the result of the side-effect. >>> The result of the side-effect is either some type decoded from some Json >>> that is received (in the case of usual requests to Json APIs) or some kind >>> of error type. >>> >>> >>> So, in the case of Http, the final Cmd is a complex request that >>> encapsulates a series of Http requests and is able to produce either a >>> success msg or a fail msg. >>> The data that end up in the messages gets there as a result of the >>> execution of said Cmd. >>> Which of the messages (success or failure) ends up in your update is >>> also predicated on the execution of the Cmd. >>> >>> >>> >>> >>> >>> >>> >>>> On Wednesday, November 16, 2016 at 2:46:41 PM UTC+1, Peter Damoc wrote: >>>>> >>>>> Sorry, old habits. >>>>> >>>>> The Http API became Cmd oriented. You don't need Task.attempt. Just >>>>> use the regular Http.get and use the Cmds produced by it. >>>>> >>>>> If you need chaining, there is a `toTask` function that converts >>>>> Requests to Tasks >>>>> >>>>> >>>>> >>>>> On Wed, Nov 16, 2016 at 3:33 PM, Tim Bezhashvyly <[email protected] >>>>> > wrote: >>>>> >>>>>> Thank. This makes lots of sense in regards of first argument. >>>>>> >>>>>> What about the second? In 0.17 it could be for example: >>>>>> >>>>>> (Http.get "my.json" decoderFunction) >>>>>> >>>>>> But not it produced an error: >>>>>> >>>>>> Function `attempt` is expecting the 2nd argument to be: Task.Task >>>>>>> Http.Error (Maybe MyType) But it is: Http.Request MyType >>>>>> >>>>>> >>>>>> >>>>>> On Wednesday, November 16, 2016 at 2:22:48 PM UTC+1, Peter Damoc >>>>>> wrote: >>>>>>> >>>>>>> The old Task.perform was creating either a success message (if it >>>>>>> succeeded) or a fail message (if it failed) >>>>>>> The current Task.perform cannot fail. It is used for Tasks that are >>>>>>> known to succeed like requesting the window size or requesting some >>>>>>> random >>>>>>> number. >>>>>>> >>>>>>> The Task.attempt takes a function that takes a result (results >>>>>>> encapsulate both the success and the failure) and produces a message >>>>>>> based >>>>>>> on that result. >>>>>>> >>>>>>> You could define something like: >>>>>>> >>>>>>> handleRequest result = >>>>>>> case result of >>>>>>> Ok val -> >>>>>>> SuccessMessage val >>>>>>> Err err -> >>>>>>> FailMessage err >>>>>>> >>>>>>> and use it like this: >>>>>>> >>>>>>> someHttpCmd = Task.attempt handleRequest someHttpRequestTask >>>>>>> >>>>>>> Alternatively, you could just have only one message that takes a >>>>>>> Result and handle each case in that message's part of the update as >>>>>>> demonstrated by the Http example: >>>>>>> http://elm-lang.org/examples/http >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Nov 16, 2016 at 3:05 PM, Tim Bezhashvyly < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Sorry again if something obvious but Im not sure how now to make >>>>>>>> async requests in 0.18.0. >>>>>>>> >>>>>>>> In 0.17.1 it was done with Task.perform where first parameter was a >>>>>>>> success Msg, second - fail Msg and third is the task which execution >>>>>>>> result >>>>>>>> is then passed to first function. >>>>>>>> >>>>>>>> As far as I understand now Task.attempt must be used but >>>>>>>> documentation is not quite comprehensive. Could someone please advise? >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "Elm Discuss" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> There is NO FATE, we are the creators. >>>>>>> blog: http://damoc.ro/ >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Elm Discuss" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> There is NO FATE, we are the creators. >>>>> blog: http://damoc.ro/ >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Elm Discuss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> There is NO FATE, we are the creators. >>> blog: http://damoc.ro/ >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
