Ok, first, try simply removing Http.toTask as that is not needed at all
there.
triggerReadingFromJson =
Http.get "shows.json" decoderColl
|> Http.send handleRequest
And second, you need a full URL for the "shows.json" not just a file name.
On Wed, Nov 16, 2016 at 10:26 PM, Tim Bezhashvyly <tim.bezhashv...@gmail.com
> wrote:
> Here is my full program:
>
> import Html exposing (..)
> import Http
> import Table exposing (defaultCustomizations)
> import Json.Decode as Json exposing (field)
> import Task
>
>
>
> main =
> Html.program
> { init = init
> , update = update
> , view = view
> , subscriptions = \_ -> Sub.none
> }
>
>
>
> -- MODEL
>
> type alias Show =
> { date : String
> , format : String
> , city : String
> }
>
> type alias Shows = List Show
>
> type alias Model =
> { shows : Maybe Shows
> , tableState : Table.State
> }
>
>
> init : ( Model, Cmd Msg )
> init =
> ( { shows = Nothing
> , tableState = Table.initialSort "Date"
> }
> , triggerReadingFromJson
> )
>
>
>
> -- UPDATE
>
>
> type Msg
> = SetTableState Table.State
> | FetchSucceed (Maybe Shows)
> | FetchFail Http.Error
>
>
> update : Msg -> Model -> ( Model, Cmd Msg )
> update msg model =
> case msg of
> SetTableState newState ->
> ( { model | tableState = newState }
> , Cmd.none
> )
>
> FetchSucceed shows ->
> ( {model | shows = shows}
> , Cmd.none
> )
>
> FetchFail _ ->
> (model, Cmd.none)
>
>
> -- VIEW
>
>
> view : Model -> Html Msg
> view { shows, tableState } =
> div [] [ viewShows shows tableState ]
>
> viewShows maybeShows tableState =
> case maybeShows of
> Nothing ->
> text "No shows to display"
> Just shows ->
> Table.view config tableState shows
>
>
> -- TABLE CONFIGURATION
>
>
> config : Table.Config Show Msg
> config =
> Table.customConfig
> { toId = .date
> , toMsg = SetTableState
> , columns =
> [ Table.stringColumn "Date" .date
> , Table.stringColumn "Format" .format
> , Table.stringColumn "City" .city
> ]
> , customizations =
> defaultCustomizations
> }
>
>
>
> -- HTTP
>
>
> triggerReadingFromJson =
> Http.toTask (Http.get "shows.json" decoderColl)
> |> Http.send handleRequest
>
>
> decoder : Json.Decoder Show
> decoder =
> Json.map3 Show
> (field "date" Json.string)
> (field "format" Json.string)
> (field "city" Json.string)
>
>
> decoderColl : Json.Decoder Shows
> decoderColl =
> Json.map identity
> (field "shows" (Json.list decoder))
>
>
> handleRequest result =
> case result of
> Ok val ->
> FetchSucceed val
> Err err ->
> FetchFail err
>
>
>
> On Wednesday, November 16, 2016 at 9:19:46 PM UTC+1, Peter Damoc wrote:
>>
>> The JSON failures are encapsulated in your Maybe, it should not pose any
>> problem. It is defensive programming and it is just fine.
>>
>> You need to provide a full function, ideally complete with signatures, in
>> order for me to try to understand why do you get that specific compiler
>> error.
>>
>> What I provided has only two lines and should have worked (in theory).
>> If you have altered it in a way that somehow reintroduces Tasks back, I
>> need to see some code in order to try to figure out what's going on there.
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 16, 2016 at 10:07 PM, Tim Bezhashvyly <tim.bez...@gmail.com>
>> wrote:
>>
>>> 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 <tim.bez...@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...@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.
