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 <[email protected] > 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 <[email protected]> >> 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 <[email protected]> >>>> 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]. >>>>> 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]. For more options, visit https://groups.google.com/d/optout.
