Re: [elm-discuss] Passing decoding results to another decoder in 0.18.0

[Kk Kruups]

Hi Tim,

For an in depth discussion on Json Decode you might want to refer to 
article on Medium about Json Decode API and Json Decode Pipeline API.

https://medium.com/@kkruups/elm-insights-c74047637206#.phhn8xvml


I would love to get your feedback on the article.

Kkruups

On Wednesday, November 16, 2016 at 8:06:26 PM UTC+9, Tim Bezhashvyly wrote:
>
> Thanks!
>
> On Wednesday, November 16, 2016 at 12:04:21 PM UTC+1, Janis Voigtländer 
> wrote:
>>
>> "fieldName" := Json.list anotherDecoder becomes field "fieldName" 
>> (Json.list anotherDecoder)
>> ​
>>
>> 2016-11-16 11:44 GMT+01:00 Tim Bezhashvyly :
>>
>>> Sorry if I'm asking something obvious but with changes to Json.Decode in 
>>> 0.18.0 I'm not quite sure how to pass results of one decoder to another.
>>>
>>> So in 0.17.1 it was:
>>>
>>> decoder : Json.Decoder SomeType
>>> decoder =
>>>  Json.object1 identity
>>>  ("feildName" := Json.list anotherDecoder)
>>>
>>> object1 becomes map,  "feildName" := Json.list becomes field 
>>> "fieldName" Json.list. Just not sure about anotherDecoder.
>>>
>>> Thank you.
>>>
>>> -- 
>>> 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.
>>>
>>
>>

-- 
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.

Re: [elm-discuss] Async requests in 0.18.0

[Peter Damoc]

On Wed, Nov 16, 2016 at 11:32 PM, Tim Bezhashvyly  wrote:

> Is is possible to read a JSON which is array of objects? Like [ {}, {}, {}
> ]? In my example I have { "shows" : [ {}, {}, {} ] } and I'm catching a
> field by name but I'm wondering if it is possible to capture root array
> node.
>

If your decoder is (Json.list decoder) than it will capture the data from a
json like [ {}, {}, {} ]

It would look like this:


decoderColl : Json.Decoder (List Show)
decoderColl =
Json.list decoder



-- 
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.

[elm-discuss] Re: Suggested edit to Json.Decode docs

[Kk Kruups]

Hi Wouter,

You might want to check out the article on Medium about Json Decode and 
Json Decode Pipeline API for in depth info on these API.

https://medium.com/@kkruups/elm-insights-c74047637206#.phhn8xvml

BR/Kkruups


On Wednesday, November 16, 2016 at 9:09:06 PM UTC+9, Wouter In t Velt wrote:
>
> In the Json.Decode docs 
>  I 
> ran into unfamiliar functions in an example in the lazy 
>  
> section.
>
> comment : Decoder Commentcomment =
>   object Comment
> |> required "message" string
> |> required "responses" (map Responses (list (lazy (\_ -> comment
>
>
> After some digging, I discovered that required function is in fact part of 
> a different package: elm-decode-pipeline 
> 
> I do not know where the `object` function is from.
>
> To save others a similar search, and to make things clearer, I would 
> suggest to remove the `object` and `required` from the examples in the docs,
> or make an explicit reference to the package(s) where the come from.
>

-- 
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.

Re: [elm-discuss] Welcome feedback on article about JSON Decoding Posted on Medium

[Kk Kruups]

Hi Duane,

Thanks for the tip. I have already updated with code blocks.

Should be an easier read now! :)

BR/

On Thursday, November 17, 2016 at 11:39:11 AM UTC+9, Duane Johnson wrote:
>
> If you'd like to clean up the code blocks, apparently `Cmd+6` does the 
> trick on medium.com:
>
>
> https://help.medium.com/hc/en-us/articles/214465537-How-can-I-include-a-code-snippet-or-block-in-a-story-
>
> On Wed, Nov 16, 2016 at 7:06 PM, Kk Kruups  > wrote:
>
>> hi folks, I just posted an article on Medium about  JSON Decoding using 
>> NoRedInk's Pipeline API and Json.Decode would love to get your feed back. 
>> Here is the link: 
>> https://medium.com/@kkruups/elm-insights-c74047637206#.r1xxsxv5h
>>
>> Thanks,
>> KK
>>
>> -- 
>> 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.
>>
>
>

-- 
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.

Re: [elm-discuss] Welcome feedback on article about JSON Decoding Posted on Medium

[Duane Johnson]

If you'd like to clean up the code blocks, apparently `Cmd+6` does the
trick on medium.com:

https://help.medium.com/hc/en-us/articles/214465537-How-can-I-include-a-code-snippet-or-block-in-a-story-

On Wed, Nov 16, 2016 at 7:06 PM, Kk Kruups  wrote:

> hi folks, I just posted an article on Medium about  JSON Decoding using
> NoRedInk's Pipeline API and Json.Decode would love to get your feed back.
> Here is the link:
> https://medium.com/@kkruups/elm-insights-c74047637206#.r1xxsxv5h
>
> Thanks,
> KK
>
> --
> 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.
>

-- 
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.

[elm-discuss] Re: elm-repl cannot find module Tuple

[David Legard]

I should have mentioned that this in on Elm 0.18.


On Thursday, November 17, 2016 at 9:24:50 AM UTC+7, David Legard wrote:
>
> Started an elm-repl session and the message came up 
>
> I cannot find the module Tuple. 
>
>
> Module 'Repl' is trying to import it.
>
>
> Any ideas?
>

-- 
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.

[elm-discuss] elm-repl cannot find module Tuple

[David Legard]

Started an elm-repl session and the message came up 

I cannot find the module Tuple. 


Module 'Repl' is trying to import it.


Any ideas?

-- 
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.

[elm-discuss] Welcome feedback on article about JSON Decoding Posted on Medium

[Kk Kruups]

hi folks, I just posted an article on Medium about  JSON Decoding using 
NoRedInk's Pipeline API and Json.Decode would love to get your feed back. 
Here is the link: 
https://medium.com/@kkruups/elm-insights-c74047637206#.r1xxsxv5h

Thanks,
KK

-- 
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.

[elm-discuss] Re: Suggested edit to Json.Decode docs

[Evan]

Those docs came from a draft API that didn't ultimately make it. I'll make 
an edit!

On Wednesday, November 16, 2016 at 5:59:52 AM UTC-8, Max Goldstein wrote:
>
> That's probably an oversight. Yes, docs for core should not reference a 
> third-party library. 

-- 
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.

Re: [elm-discuss] Re: ANN: update-clock for fixed-time-step game loops

[Nick H]

Sorry about that. Thanks for taking proper credit!

On Wed, Nov 16, 2016 at 9:23 AM, Rex van der Spuy 
wrote:

> Wow, that's absolutely brilliant!!!
> (My username was `d13` by the way - so that was me!)
> Congratulations!!!
>
> --
> 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.
>

-- 
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.

Re: [elm-discuss] Async requests in 0.18.0

[Tim Bezhashvyly]

Great! Thanks a lot.

And if we already stared talking about decoders I have one last (absolutely 
academic) question.

Is is possible to read a JSON which is array of objects? Like [ {}, {}, {} 
]? In my example I have { "shows" : [ {}, {}, {} ] } and I'm catching a 
field by name but I'm wondering if it is possible to capture root array 
node.

On Wednesday, November 16, 2016 at 10:16:12 PM UTC+1, Peter Damoc wrote:
>
>
> On Wed, Nov 16, 2016 at 10:50 PM, Tim Bezhashvyly  > wrote:
>
>> Makes sense but doesn't change much:
>>
>> (|>) is expecting the right side to be a: Http.Request Shows -> a But 
>>> the right side is: Http.Request (Maybe Shows) -> Cmd Msg
>>
>>
> Ok, now we're cooking. 
>
> You have a Json decoder that produces Shows and it needs to produce Maybe 
> Shows. 
>  
> If you use Just instead of identity you should be fine:
>
> decoderColl : Json.Decoder (Maybe Shows)
> decoderColl =
> Json.map Just
> (field "shows" (Json.list decoder))
>
>
>
> Just to clarify a little bit more around this. If you throw bad JSON at a 
> decoder you will get a  BadPayload Http.Error as the result of the request. 
> If you want to capture the failure of the decoder within the decoder you 
> need something like this: 
>
> decoderColl : Json.Decoder (Maybe Shows)
> decoderColl =
> Json.maybe (field "shows" (Json.list decoder))
> 
> This second decoder will not throw a BadPayload because it will be able to 
> decode every bad JSON to Nothing.
> This is useful in some ways but BadPayload errors are more informative. 
>
>
>
>
> -- 
> 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.

Re: [elm-discuss] Async requests in 0.18.0

[Peter Damoc]

On Wed, Nov 16, 2016 at 10:50 PM, Tim Bezhashvyly  wrote:

> Makes sense but doesn't change much:
>
> (|>) is expecting the right side to be a: Http.Request Shows -> a But the
>> right side is: Http.Request (Maybe Shows) -> Cmd Msg
>
>
Ok, now we're cooking.

You have a Json decoder that produces Shows and it needs to produce Maybe
Shows.

If you use Just instead of identity you should be fine:

decoderColl : Json.Decoder (Maybe Shows)
decoderColl =
Json.map Just
(field "shows" (Json.list decoder))



Just to clarify a little bit more around this. If you throw bad JSON at a
decoder you will get a  BadPayload Http.Error as the result of the request.
If you want to capture the failure of the decoder within the decoder you
need something like this:

decoderColl : Json.Decoder (Maybe Shows)
decoderColl =
Json.maybe (field "shows" (Json.list decoder))

This second decoder will not throw a BadPayload because it will be able to
decode every bad JSON to Nothing.
This is useful in some ways but BadPayload errors are more informative.




-- 
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.

[elm-discuss] Re: Checkbox example

[Desmond D'Souza]

Try feeding the model property through to *view* :

view : Model -> Html Msg
view model =
  fieldset []
[ checkbox model.notifications ToggleNotifications "Email Notifications"
, checkbox model.autoplay ToggleAutoplay "Video Autoplay"
, checkbox model.location ToggleLocation "Use Location"
]


checkbox : Bool -> msg -> String -> Html msg
checkbox b msg name =
  label
[ style [("padding", "20px")]
]
[ input [ type_ "checkbox", onClick msg, checked b ] []
, text name
]


Seems to work. Then change *update *to this:

update : Msg -> Model -> Model
update msg model =
  case msg of
ToggleNotifications ->
  { model | notifications = True } -- instead of { model | 
notifications = not model.notifications }
...
...

So although Elm is feeding *True* to view, the checkbox seems to ignore 
that input and render its own internal state. So feeding it anything (the 
current model value or otherwise) does nothing once it is created ... 

Not sure what virtual dom is doing with its diff in these cases, or if this 
behavior is expected [for any stateful component] and reasonable. Would 
like to know, though.

 

On Wednesday, November 16, 2016 at 10:56:02 AM UTC-6, Mark Hamburg wrote:
>
> The checkbox example on the Elm site initializes the model to have all the 
> checkboxes set, but does not reflect this state when it runs since it never 
> feeds the model values through to the view. 
>
> I notice this in a lot of Elm examples. For example, the sign up form 
> example doesn't populate the model values into the text fields. Is this 
> just a case on relying on the model having been initialized in the same way 
> the fields default and then just expecting to track changes? That seems 
> like a bad pattern in more common practice. 
>
> Mark 
>
>

-- 
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.

Re: [elm-discuss] Async requests in 0.18.0

[Tim Bezhashvyly]

And just file name works fine as it in the same dir as elm file.

On Wednesday, November 16, 2016 at 9:40:45 PM UTC+1, Peter Damoc wrote:
>
> 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  > 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  
>>> 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  > 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 

Re: [elm-discuss] Async requests in 0.18.0

[Tim Bezhashvyly]

Makes sense but doesn't change much:

(|>) is expecting the right side to be a: Http.Request Shows -> a But the 
> right side is: Http.Request (Maybe Shows) -> Cmd Msg

 

On Wednesday, November 16, 2016 at 9:40:45 PM UTC+1, Peter Damoc wrote:
>
> 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  > 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  
>>> 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  > 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 

Re: [elm-discuss] Async requests in 0.18.0

[Peter Damoc]

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  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 
>> 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 
 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 

[elm-discuss] Re: Checkbox example

[Desmond D'Souza]

Try changing *update *to this:

 { model | notifications = True } -- instead of { model | notifications = 
not model.notifications }

Stateful elements, including checkboxes, seem to ignore what Elm tells 
them, and simply use their own internal current state. Not sure what 
virtual dom is (or should be) doing in these cases.


On Wednesday, November 16, 2016 at 10:56:02 AM UTC-6, Mark Hamburg wrote:
>
> The checkbox example on the Elm site initializes the model to have all the 
> checkboxes set, but does not reflect this state when it runs since it never 
> feeds the model values through to the view. 
>
> I notice this in a lot of Elm examples. For example, the sign up form 
> example doesn't populate the model values into the text fields. Is this 
> just a case on relying on the model having been initialized in the same way 
> the fields default and then just expecting to track changes? That seems 
> like a bad pattern in more common practice. 
>
> Mark 
>
>

-- 
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.

Re: [elm-discuss] Async requests in 0.18.0

[Tim Bezhashvyly]

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  > 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  
>>> 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  > 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 

Re: [elm-discuss] Async requests in 0.18.0

[Tim Bezhashvyly]

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  > 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  
>>> 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  > 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 

Re: [elm-discuss] Async requests in 0.18.0

[Peter Damoc]

On Wed, Nov 16, 2016 at 8:19 PM, Tim Bezhashvyly 
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 
>> 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 
 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 

Re: [elm-discuss] Async requests in 0.18.0

[Tim Bezhashvyly]

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  > 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  
>>> 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  > 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 

[elm-discuss] Re: ANN: update-clock for fixed-time-step game loops

[Rex van der Spuy]

Wow, that's absolutely brilliant!!!
(My username was `d13` by the way - so that was me!)
Congratulations!!!

-- 
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.

[elm-discuss] Checkbox example

[Mark Hamburg]

The checkbox example on the Elm site initializes the model to have all the 
checkboxes set, but does not reflect this state when it runs since it never 
feeds the model values through to the view.

I notice this in a lot of Elm examples. For example, the sign up form example 
doesn't populate the model values into the text fields. Is this just a case on 
relying on the model having been initialized in the same way the fields default 
and then just expecting to track changes? That seems like a bad pattern in more 
common practice.

Mark

-- 
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.

[elm-discuss] Re: Converting a UTC date to a local one?

[Justin Mimbs]

What format are you receiving your UTC dates in?

If they are proper ISO 8601 strings, then you can get the expected Date 
with `fromIsoString` from here: 
http://package.elm-lang.org/packages/justinmimbs/elm-date-extra/2.0.1/Date-Extra#fromIsoString.
 
To be recognized as UTC time the string must include a time zone offset of 
"+00", "+", "+00:00", or "Z", e.g. "2016-11-16T14:00Z". If no time zone 
offset is present, the string is assumed to represent local time.

If you have date parts that represent a UTC time, then you can construct 
the expected Date with `fromSpec`, 
http://package.elm-lang.org/packages/justinmimbs/elm-date-extra/2.0.1/Date-Extra#fromSpec.


import Date.Extra exposing (utc, atTime, calendarDate)

Date.Extra.fromSpec
  utc
  (atTime 14 0 0 0)
  (calendarDate 2016 Nov 16)



Once you have a Date representing the desired UTC time, then its 
extractions will represent the machine's local time. Formatting functions 
usually default to representing the date in local time too. Does this help?



On Tuesday, November 15, 2016 at 10:27:57 PM UTC-5, Liam Curry wrote:
>
> I have some UTC dates that I need to show in the users local time. All I 
> really need is the users local timezone offset, which I can then use to 
> calculate the date in their local timezone.
>
> I've looked over several Date/Time packages and none of them seem to do 
> this. Am I missing something, or is there no easy way to do this in Elm 
> without using Native code?
>

-- 
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.

Re: [elm-discuss] Async requests in 0.18.0

[Tim Bezhashvyly]

Chained to Task.andThen and Task.onError? And what those tow must return? I 
assume commands as they can't change model directly, right?

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  > 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  
>>> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Suggested edit to Json.Decode docs

[Max Goldstein]

That's probably an oversight. Yes, docs for core should not reference a 
third-party library. 

-- 
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.

Re: [elm-discuss] Async requests in 0.18.0

[Tim Bezhashvyly]

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  > 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Async requests in 0.18.0

[Peter Damoc]

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 
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+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.

Re: [elm-discuss] Async requests in 0.18.0

[Janis Voigtländer]

Where in 0.17 you had Task.perform f g, you can replace that in 0.18 by
simply Task.attempt (unpack f g), where unpack is from
http://package.elm-lang.org/packages/elm-community/result-extra/2.0.1.
​

2016-11-16 14:05 GMT+01:00 Tim Bezhashvyly :

> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.

[elm-discuss] Suggested edit to Json.Decode docs

[Wouter In t Velt]

In the Json.Decode docs 
 I 
ran into unfamiliar functions in an example in the lazy 
 
section.

comment : Decoder Commentcomment =
  object Comment
|> required "message" string
|> required "responses" (map Responses (list (lazy (\_ -> comment


After some digging, I discovered that required function is in fact part of 
a different package: elm-decode-pipeline 

I do not know where the `object` function is from.

To save others a similar search, and to make things clearer, I would 
suggest to remove the `object` and `required` from the examples in the docs,
or make an explicit reference to the package(s) where the come from.

-- 
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.

Re: [elm-discuss] Re: Correct use of port subscriptions in a submodule reused multiple times?

[Witold Szczerba]

Thanks for the extended feedback :)
I will be back here once I have something big enough!

Regards,
Witold Szczerba

On Wed, Nov 16, 2016 at 10:13 AM, Wouter In t Velt  wrote:

> Op dinsdag 15 november 2016 23:03:31 UTC+1 schreef Witold Szczerba:
>>
>> Thank you, Wouter for explanation. I was reading the documentation, but
>> the chapter covers just the reusable views. View functions seems fine,
>> using modules one can create, group, nest, etc.
>>
>
> You are right that the example is mostly about views, but the principles
> apply to other bits as well.
>
>
>> I am wondering how making everything "flat" scales in a long term.
>>
>
> In the SPA I developed, I started out with a simple structure with
> Main.elm, Update.Elm, Msg.elm, Model.elm.
>
> At some point I needed a datepicker, and built one with Elm. I started of
> with a DatePicker.elm module, which I put inside a separate Views folder.
> The DatePicker also required some additional messages: HandleUpMonth,
> HandleDownMonth, DateSelected Date. And somewhere in my update, these
> messages need to be handled. And somewhere in my model, I needed to keep
> track of the currentMonth, in view in the DatePicker. (so the DatePicker
> view knows which month to display).
> I started out by simply adding stuff to Msg.elm, Update.elm and Model.elm.
> Putting the extra info in the model at the highest level on purpose. So my
> structure remained flat, not nested.
>
> In the next round, I found out that actually processing the selected date
> required quite a bit of code, to do the correct validations, update the
> right record in my data structure, and close my DatePicker page.
>
> This was related to the data update, not to the DatePicker, so I created a
> separate module for Exams, which handles the validation and updates for the
> exam.
>
> At this point, my folder structure was something like this:
>
> src
> |- Main.elm
> |- Model.elm
> |- Msg.elm
> |- Update.elm
> |- Updates (folder)
>|- Exams.elm
> |- View.elm
> |- Views (folder)
>|- DatePicker.elm
>
>
> The nice thing about scaling in this way, is that the compiler has your
> back: once you add messages in Msg.elm, the compiler will complain that you
> need to change something in your Update.elm, because not all Msg are
> handled there. So it is not a big deal that your DatePicker view function
> and the related Msg are in different files. The compiler will protect their
> consistency.
>
> In short, the way I scale is simply:
>
>- Only put different pages in different view modules (and import them
>in the overall View.elm)
>- Everything else: simply put it in Msg.elm, Update.elm, etc. And only
>if one of these files becomes too big (300-400 lines is my threshold), take
>out stuff and put it in a separate module.
>
> By now, my app is getting pretty big. But it remains very managable.
> I use the DatePicker now in several different places, and the flat
> structure still works for me.
>
> Hope this helps!
>
> --
> 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.
>

-- 
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.

Re: [elm-discuss] Help for article review for SPA applications in Elm 0.18

[Adrián Ribao]

Hi, thanks! and than you for your suggestions!

I think that explaining in the beginning what you can learn from the post 
is a very good idea.

Thanks for your feedback because it was really helpful.

Adrián

El martes, 15 de noviembre de 2016, 23:14:47 (UTC+1), Wouter In t Velt 
escribió:
>
> Great article!
> I really like the way that you take the reader step by step through 
> building a basic SPA, which even includes navigation and url parsing.
>
> Personally, I think it is fine to let the reader "play along" by making a 
> local copy and work on that. It would be useful if you point out that the 
> "localhost" links only work if reader already has elm-reactor running. But 
> I guess the point you are trying to make is that your app allows user to 
> type these urls in the browser.
> Maybe keep the urls, but remove the links?
> In general, it would be nice to have links to a working example, possibly 
> on gh-pages.
>
> As general feedback: Because it is quite a long read,  adding an explicit 
> comment in the beginning of what you hope the reader will learn from your 
> post would be useful. E.g. "demonstrate that it is easy and fun to scale 
> Elm, that your code remains readable", or "if you are learning Elm, or want 
> to build a SPA for yourself, here is an example to get you started".
>
> I've added some minor comments on typo's and readibility in the article 
> too.
> Suggest that you make function calls to imported functions explicit, e.g. 
> Navigation.newUrl instead of newUrl.
> Make it clear to readers whether a function is defined by you or imported 
> (and from where).
>
> Thanks for sharing this! 
> Really useful, I have just begun to refactor a SPA to 0.18, and your 
> explanation of the new navigation module was really helpful.
>

-- 
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.

Re: [elm-discuss] Listening to messages from different modules on an update

[Peter Damoc]

You need to map the submodule Cmd to the top module Cmd

init : ( Model, Cmd Msg )
init =
 ( {
 -- my model here
 }
 , Cmd.map AMsg getJson
 )

(as OvermindDL1 pointed aMsg is not a valid type constructor)



On Wed, Nov 16, 2016 at 12:50 AM, Tim Bezhashvyly  wrote:

> Thank you. Tried to apply it but my problem is that I'm trying to send
> initialize a request on init:
>
> init : ( Model, Cmd Msg )
> init =
>  ( {
>  -- my model here
>  }
>  , getJson
>  )
>
> And of course `getJson` is returning `A.Msg`, so even if in B I declare:
>
> type Msg
>  = aMSG A.Msg
>  | SomeLocalMessage
>
>
> I'm still getting an error that init was expecting `Main.Msg` but got
> `A.Msg`.
>
> Hope I make sense.
>
>

-- 
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.