You mean something like: triggerReadingFromJson = Http.toTask (Http.get "my.json" decoder) |> Task.andThen (\result -> Task.succeed result) |> Task.onError (\error -> Task.fail error)
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] > <javascript:>> 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] <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.
