On Wed, Nov 16, 2016 at 8:19 PM, Tim Bezhashvyly <tim.bezhashv...@gmail.com>
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 <tim.bez...@gmail.com>
>> 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 <tim.bez...@gmail.com>
>>>> 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 <
>>>>>> tim.bez...@gmail.com> 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 elm-discuss...@googlegroups.com.
>>>>>>> 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 elm-discuss...@googlegroups.com.
>>>>> 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 elm-discuss...@googlegroups.com.
>>> 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 elm-discuss+unsubscr...@googlegroups.com.
> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
