Re: [elm-discuss] Re: State of CSS in Elm

[Wouter In t Velt]

Really interesting discussion and viewpoints. As  newcomer and hobbyist in the 
elm arena, some may think this naive, but I find the principle to separate 
concerns very appealing.
Meaning (simply put) the DOM (html) is for the component structure, CSS is for 
layout, and JavaScript is for interaction.
IMHO, the fuzziness we have to deal with is because each of the 3 building 
blocks is lacking features that we need.
Which is why so many web apps/ sites end up with messy DOM trees with loads of 
unwanted div layers, and messy Jquery as a band-aid for styling deficiencies.

In learning elm (coming from react), I really like the functional and pure 
aspects of it.
But I really wish I would be able to keep styling and transitions for state 
changes separate, preferably with styling in CSS stylesheets.

Especially for transitions.

I try to have my elm code render only twice, and let CSS would take care of 
transition. Seperates concerns, and keeps code clean. Is the right class 
applied in state 1? And in state 2? Then elm is fine. Layout and transition 
wrong? Must be CSS.
Adding a subscription in elm to every single of 500 animation frames + 
extending model to not only save state but also all 
in-between-two-discrete-states information, feels like an unwanted complication 
and mixture of concerns.

I see benefits of DOM + styling + interaction mix in components (reminds me of 
Polymer).
And I dislike the cascading aspect (and other shortcomings) of pure CSS, and it 
is hard to switch back and forth between elm and CSS mindset.
Not sure of I can keep transitions from blending, and the will definitely 
investigate elm CSS solutions mentioned.

But for now, I still believe code will be cleaner and more maintainable as it 
grows, if one persists to separate the styling on the one hand from the content 
and interaction in the other.

-- 
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: Communicating from parent to child and child to parent

[Wouter In t Velt]

Thanks for sharing. The additional OutMsg from the update function was a 
real eye-opener for me.
I have no experience (yet) in scaling this.

One thing I find somewhat odd in your (second) example is that you define 
the OutMsg type in the Child:
Wouldn't it be more logical to always define/ manage Message types in the 
component that actually handles these Messages and has an update function 
for this?

In your example, the parent is the Owner of the OutMsg: the parent has 
separate update function(s) for dealing with each of the OutMsg types.
To prevent circular import references (parent importing child, and child 
importing parent), one would need to separate out parent and child into 
separate files (as in the - not 0.17 yet - example of the Players in the 
Elm docs).

That way, any child component of parent can import the OutMsg type (maybe 
ParentPublicMsg would be a more appropriate name). Then the parent exposes 
this type for any child that wishes to send out such a message. When you 
then expand OutMsg with, say AskForMoreAllowance, you add it to the 
parent-owned type + to the parent's update function. Children can be 
updated to respond to the new OutMsg type, but better still: any child 
component which is not updated will continue to work.

My specific use case: I have a list of children with a number of internal 
messages (e.g. updates on each child). One of the functions I need to 
implement is 'RemoveMeFromList', which is a button on each child. This 
message type can only be handled by the parent, through removing child from 
list and no longer rendering it in view.

-- 
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: Is there a better way to structure my List types?

[Wouter In t Velt]

How about this?

type Thing =
  Foo
  | Bar
  | Baz


type ThingList = List Thing



That way, you can simply do:

List.length ThingList

-- 
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: Design of Large Elm apps

[Wouter In t Velt]

Thank you Peter for sharing the sortable table and especially the video link!
Video has a somewhat long winded exploration in accessibility in the early 
part, but I found it most helpful.

The thoughts on config and even updateConfig were really helpful. Also the idea 
to have an update take in 1 message type and output another message type is 
food for thought. Got me to rethink my own setup of child-to-parent 
communication.

I can definitely recommend both links!

-- 
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: [ANN] elm-mdl 7.0.0 — supports all components of Material Design Lite

[Wouter In t Velt]

Congrats on the great achievement, and thank you for contributing this to 
the community! 
Will update asap.

-- 
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 fiddle for 0.17?

[Wouter In t Velt]

>From the GitHub Readme  of 
Elm Fiddle:

Unfortunately most work on this was made before 0.17 was released, and it 
> was written for 0.16,


and 

It's far from being production ready, so it might crash and your snippets 
> may be deleted. Adding to that, the code is smelly and was my first attempt 
> in building something real with Elm, and playing around with it in the 
> server. 


So yeah, I guess it is not 0.17 ready. Looks really cool though.

-- 
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 fiddle for 0.17?

[Wouter In t Velt]

PS: Whenever I want to try some Elm online, I go to http://elm-lang.org/try
Which does run 0.17 under the hood (as far as I can tell).

-- 
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] Sending messages up the component tree in Elm 0.17

[Wouter In t Velt]

A solution I am currently experimenting with is to wrap the Msg of each 
component into a union type:

type AddressedMsg =
  ToSelf Msg
  | ToParent OutMsg
  | ToRoot RootMsg

All relevant functions of the component which output ( Model, Cmd Msg ) change 
to ( Model, Cmd AddressedMsg )

The update function (of any component in the tree) is now:

update : AddressedMsg -> Model -> ( Model, AdressedMsg )
update msg model =
  case msg of
ToSelf msg' ->
   handleMsg msg' model
ToParent outMsg ->
   -- translate outMsg to new message for parent

Inside the view, I bundled my taggers to include the address, e.g. 'ToSelf 
Increment' to increase counter 'ToParent RemoveMe' to notify parent counter 
needs to be removed.

Inside parent's update function is similar and the confidentiality is 
preserved. Whenever the parent of this component is called (e.g Modify 5 msg in 
case of the counter).
When the Msg is of type ToSelf, then the parent calls the update of the child.

-- 
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: Communicating from parent to child and child to parent

[Wouter In t Velt]

I hope I interpret your setup correctly, but it looks like the flow is more 
or less:

   - user clicks a button inside child
   - this triggers child's update function
   - child's update function stores updates child model (with a message 
   Click)
   - the parent can then access the new function by accessing the child's 
   model

What I do not understand is: you mention an UpdateButton message that the 
parent responds to,
But what triggers this message?
Typically, the parent does not know or care about child model contents or 
child model updates. The parent receives child messages, but parent does 
not read child messages. Parent simply passes the messages on the child's 
update function, and stores the updated child model.

This separation guarantees that you can modify code in your child component 
(e.g. change the child model, add new message types etc), and any parent 
will continue to work properly. No need to check or change code in any 
other component that imports the child.
If any parent 'looks inside' the model or the messages of the child, then 
this guarantee breaks down.

The discussion here (or at least my interest in this) is:
How do I communicate a message from a child to parent, while at the same 
time maintaining the integrity of the child's model (so no peeking by 
parents into child model)?

-- 
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: Communicating from parent to child and child to parent

[Wouter In t Velt]

Hi Rex,

I hope I interpret your setup correctly, but it looks like the flow is more 
or less:


   - user clicks a button inside child
   - this triggers child's update function
   - child's update function stores updates child model (with a message 
   Click)
   - the parent can then access the new function by accessing the child's 
   model
   
What I do not understand is: you mention an UpdateButton message that the 
parent responds to,

But what triggers this message?

Typically, the parent does not know or care about child model contents or 
child model updates. The parent receives child messages, but parent does 
not read child messages. Parent simply passes the messages on to the 
child's update function, and stores the updated child model.

 

This separation guarantees that you can modify code in your child component 
(e.g. change the child model, add new message types etc), and any parent 
will continue to work properly. No need to check or change code in any 
other component that imports the child.

If any parent 'looks inside' the model or the messages of the child, then 
this guarantee breaks down.

 

The discussion here (or at least my interest in this) is:

How do I communicate a message from a child to parent, while at the same 
time maintaining the integrity of the child's model (so no peeking by 
parents into child model)?

 

-- 
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: [ANN] elm-mdl 6.0.0 released

[Wouter In t Velt]

Looks awesome! Thanks! Definitely a great set of building blocks for shiny apps!

-- 
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] Learning Elm and feeling alone in the world

[Wouter In t Velt]

Great discussion! I am looking forward to seeing progress on the Learn You an 
Elm.

Having learned quite a few languages in my days, I actually find it quite 
refreshing to dive into a new and promising language as Elm.
With many other languages (Java anyone?) it was a nightmare to find a suitable 
(and not outdated) starting point among gazillions of options, tutorials, 
courses, libraries, frameworks etc.

Yes Elm has gaps to be filled, tutorials and guides still in development, and 
libraries to mature. And for many questions the answer is not yet out there or 
hard to find, especially for the infix stuff (try Googling what "::"  means).

And I find the community very supportive (evidence in this threat).
The docs on elm-Lang.org got me a long way, and I hope I can continue to steer 
clear of docs from other languages like Haskell (haven't read LYaH).

-- 
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: Is there a reason Date has no setters?

[Wouter In t Velt]

For something similar to your need, I have actually created my own SimpleDate 
type ( year, month, day, weekday) without time.
Born out of frustration after endless mapping of Result types. 

The very first SimpleDate created from a String is a Result (using 
.fromString). But after that, helper functions allow you to create new 
SimpleDates by passing in a valid SimpleDate and an offset in days, or go to 
first of week, month, year etc etc.
I used it for building a simple date picker.
If anyone is interested, I can add some basic documentation and try sharing on 
GitHub.

But off course I would welcome similar extended date methods in the core 
(preferably returning valid dates, not Results BTW).

-- 
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 Routing with Navigation in 0.18

[Wouter In t Velt]

Op zondag 5 februari 2017 20:51:03 UTC+1 schreef Kingsley Hendrickse:
>
> I'm struggling a bit to get what I want out of the Route and Navigation 
> libraries.
>

Some time ago, I wrote a couple of posts diving into Navigation and Routing 
in Elm:
https://medium.com/elm-shorts/choosing-the-right-elm-spa-architecture-d6e8275f6899?source=collection_home---5--1--
https://medium.com/elm-shorts/more-on-spa-navigation-in-elm-31a066c6b9ae?source=collection_home---5--3--

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.

[elm-discuss] Re: Design question: using Dict, List with index, or Array (or something I'm not aware of)

[Wouter In t Velt]

Touche, I had an omission in my snippet also :)
The getItem should have been:

getItem : List Item -> ID -> Maybe Item
getItem : list id =
  List.filter (\item -> item.id == id) list
  |> List.head


To turn the (maybe empty) list of with the item-to-get into a Maybe Item.

I did use a lot of Dict also for data, but in my code that frequently 
generated a lot of turning Dict into Lists (for rendering, sorting, 
filtering, counting etcetera).
But I guess it depends on typical use case.

-- 
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: Basic behavioral composition

[Wouter In t Velt]

Hadn't noticed this section in the guide before. Great explanation!
Thanks for sharing.

Op vrijdag 2 september 2016 18:00:31 UTC+2 schreef suttlecommakevin:
>
> This new doc helps a ton. Thanks for this!
>
> http://guide.elm-lang.org/reuse/
>

-- 
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: Do the counters in the Guide teach us a wrong scaling approach?

[Wouter In t Velt]

After reading Josh Adams Time tracker SPA example something really clicked for 
me, and I feel I really "get it" now.
I did not know what I needed and how to ask for it, but this was extremely 
helpful, and got me back on track!

Also, I think my OP about the counters can be considered closed now. The guide 
has (recently) been updated with a great walk through of how to scale elm.

>From another thread (thanks to suttlecommakevin for sharing):
http://guide.elm-lang.org/reuse/

-- 
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: html-to-elm

[Wouter In t Velt]

Nice tool!
Do you plan on adding "style" and other odd shaped Elm attributes like 
"disabled" too?

-- 
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: Elm Runtime Exceptions

[Wouter In t Velt]

Interesting post, but I tend to disagree on a couple of points:

According to the oracle Java tutorial 
, 
an exception is 

> *Definition:* An *exception* is an event, which occurs during the 
> execution of a program, that disrupts the normal flow of the program's 
> instructions.


In Elm, there are types for special cases, such as the Maybe type, which 
can be "nothing". Whether or not we call these "exceptions" is beside the 
point IMHO.

What does matter is IF and HOW the language makes you deal with them.

With Elm, the compiler will tell you if you fail to handle these special 
cases. Elm is built in such a way that 99,999% of the time, your exceptions 
are not allowed to go unchecked to runtime.

In many other languages, handling these special cases is optional, which is 
a bad thing:
If these exceptions show up in tests, it is often harder to locate the 
source, and harder to fix.
Any exceptions which are not covered in tests (a very common scenario), 
lowers the quality of the products we ship and our users suffer.

In my experience, Elm does not force me to handle all special cases at the 
lowest possible level. You are free to pass around Maybe types and Result 
types to wherever you want to handle them,

Or, put another way, if one day Java decided to make *all* exceptions 
> checked, then Java, too, could claim “*no runtime exception”*. But it 
> would make programming much more difficult.


Forcing exceptions to be checked = more code, agreed. But programming 
difficulty = code + debugging + fixing. 
One could easily make the claim that forcing checked exception handling = 
easier programming.
Any ease of programming from unchecked exceptions is really deferred work 
to testing and/or lower quality of shipped product.

-- 
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] When to use Dict vs. List?

[Wouter In t Velt]

List and Dict are good for different things:
If most of the interaction with the collection is getting and setting, adding 
and deleting items 1 at a time: go with Dict.
If most of the interaction is going over the list, including sorting, 
rendering, counting items etc: then go with List.

Todo's in the example at more or less in the middle. List is simpler, so that 
would most sense.

Not sure what you mean with:
" Maybe.map doesn't appear useful as record updates aren't compose-able?)" 

I think you can do something like:

{ model | myCollection = Dict.update key (Maybe.map <| itemUpdate newText) 
model.myCollection }

-- 
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: How to order imports?

[Wouter In t Velt]

Good question to raise! The lack of any logic in my own imports had on 
occasion nagged me too.

This is our convention:
>
> 1) Core modules;
> 2) Public modules from elm-lang;
> 3) Other public modules;
> 4) Project modules.
>

The one @Simone Vittori suggests looks simple and workable.

-- 
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: Do the counters in the Guide teach us a wrong scaling approach?

[Wouter In t Velt]

>
> Here's what I've been working on.  The recent git history is all about 
> refactoring.  Haven't introduced 'sub-components with state' or w/e and 
> don't see it coming soon.  It's an Elm-SPA with a Phoenix backend: 
> https://github.com/knewter/time-tracker
>

Looks interesting. Thanks for sharing!
First impression is that you have somehow managed to do stuff in about 1/10 
the amount of code I typically end up with.
I'll dive deeper to try and understand how you did that/ where my 
inefficiencies are!

-- 
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: Do the counters in the Guide teach us a wrong scaling approach?

[Wouter In t Velt]

>
> I would love to know how to do this!
> Can anyone point me to a brain-dead-simple practical and working example 
> for a non-expert Elm user like myself?


OK, so here is my take at an alternative multiple counters approach.
First, putting everything in one (monolithic) module:

import Html exposing (Html, div, button, text)
import Html.App exposing (beginnerProgram)
import Html.Events exposing (onClick)
import Html.Attributes exposing (style)

main =
  beginnerProgram 
{ model = defaultModel
, view = view
, update = update 
}

{- Model needs to hold a list of counter values
For clarity, we define an alias for CounterValue
The uid of the original counter list Model is not really needed
Any counter in the list is simply identified by its index
-}
type alias Model =
  List CounterValue
  
type alias CounterValue =
  Int

-- the defaultmodel is simply an empty list
defaultModel : Model
defaultModel = 
  []

{- Original Msg type needs to be expanded to include the ID of the counter
to update. So our update function knows which counter to change.
We could have done something like a nested Msg structure:

type alias Msg =
  AddCounter
  | ForCounter CounterId CounterMsg
  
type alias CounterMsg =
  Increment
  | Decrement
  
But no need to make things more complicated than needed, so we keep things 
simple
-}
type Msg =
  AddCounter
  | Increment CounterId
  | Decrement CounterId
  
type alias CounterId =
  Int


{- Update takes the message and update model (duh ;), 
using a helper function to update the right counter (indicated by index from 
Msg)
in its list
-}
update : Msg -> Model -> Model
update msg model =
  case msg of

AddCounter ->
  -- add new counter with default value of zero to our list
  model ++ [ 0 ]
  
Increment counterId ->
  -- invoke helper to increment item at index
  changeItemInList counterId (\item -> item + 1) model

Decrement counterId ->
  -- invoke helper to decrement item at index
  changeItemInList counterId (\item -> item - 1) model


-- helper to update an item in any list, applying a function to item at 
index
changeItemInList : Int -> (a -> a) -> List a -> List a
changeItemInList idToUpdate itemUpdate someList =
  List.indexedMap (setItemAtIndex idToUpdate itemUpdate) someList
  
-- apply itemUpdate function if index matches idToUpdate
setItemAtIndex : Int -> (a -> a) -> Int -> a -> a
setItemAtIndex idToUpdate itemUpdate index a =
  if (idToUpdate == index) then
itemUpdate a
  else
a


{- view renders a button to add a counter + list of counters from model
-}
view : Model -> Html Msg
view model =
  let
countersHtml =
  List.indexedMap counterView model
  in
div []
  [ button [ onClick AddCounter ] [ text "Add counter" ]
  , div [ style [("display","flex")] ]
  countersHtml
  ]

-- helper to render a counter, we need the index to include in message
counterView : Int -> CounterValue -> Html Msg
counterView index counterValue =
  div [ style [("flex","0 0 32px")]]
[ button [ onClick (Increment index) ] [ text "+" ]
, div [] [ text (toString counterValue) ]
, button [ onClick (Decrement index) ] [ text "-" ]
]


A note here:

   - Looping over the entire list of counters to update one single counter, 
   with the update helpers, feels inefficient. An alternative is to use Dict, 
   and get the item to update. But then each branch in the update is around 10 
   instead of 1 line, because get returns a Maybe type, and we have to factor 
   this in.
   


I would do the separation of view function of an individual counter as 
follows:

The original module (as above) would only require 2 changes:

...
-- import our newly separated view function
import CounterView

...

-- the helper function is changed: we now call the view function on our 
imported module, and pass our Msg types + counter value
counterView : Int -> CounterValue -> Html Msg
counterView index counterValue =
  CounterView.view (Increment index) (Decrement index) counterValue


The separated CounterView.elm module is:
module CounterView exposing (..)

import Html exposing (Html)

{- our view function takes 3 arguments:
  1. some Increment message (of any type, therefore in lowercase)
  2. some decrement message
  3. an Int with the counter value to display

The output is Html + the msg type of the 2 input messages.
So our view function, and this module do not own the message type.

Could have put the static parts (the 2 messages) in a config record, like 
the elm-sortable-table,
but for just 2 input variables, a record feels like overkill
-}
view : msg -> msg -> Int -> Html msg
view incrementMsg decrementMsg counterValue =
  div [ style [("flex","0 0 32px")]]
[ button [ onClick incrementMsg ] [ text "+" ]
, div [] [ text (toString counterValue) ]
, button [ onClick decrementMsg ] [ text "-" ]
]


Note here:

   - The API of this view function is msg -> msg -> 

[elm-discuss] Re: Do the counters in the Guide teach us a wrong scaling approach?

[Wouter In t Velt]

>
> I would love to know how to do this!
> Can anyone point me to a brain-dead-simple practical and working example 
> for a non-expert Elm user like myself?

OK, so here is my take at an alternative multiple counters approach.
import Html exposing (Html, div, button, text)
import Html.App exposing (beginnerProgram)
import Html.Events exposing (onClick)
import Html.Attributes exposing (style)
import CounterView -- our separated view function

main =
  beginnerProgram 
{ model = defaultModel
, view = view
, update = update 
}

{- Model needs to hold a list of counter values
Any counter in the list is simply identified by its index
-}
type alias Model =
  List CounterValue
  
type alias CounterValue =
  Int

-- the defaultmodel is simply an empty list
defaultModel : Model
defaultModel = 
  []

{- Original Msg type needs to be expanded to include the ID of the counter
to update. So our update function knows which counter to change.
We could have done something like a nested Msg structure:
type alias Msg =
  AddCounter
  | ForCounter CounterId CounterMsg
  
type alias CounterMsg =
  Increment
  | Decrement
  
But no need to make things more complicated than needed, so we keep things 
simple 
-}
type Msg =
  AddCounter
  | Increment CounterId
  | Decrement CounterId
  
type alias CounterId =
  Int

{- Update takes the message and update model (duh ;), 
using a helper function to update the right counter (indicated by index from 
Msg)
-}
update : Msg -> Model -> Model
update msg model =
  case msg of

AddCounter ->
  -- add new counter with default value of zero to our list
  model ++ [ 0 ]
  
Increment counterId ->
  -- invoke helper to increment item at index
  changeItemInList counterId (\item -> item + 1) model

Decrement counterId ->
  -- invoke helper to decrement item at index
  changeItemInList counterId (\item -> item - 1) model

-- helper to update an item in any list, applying a function to item at 
index
changeItemInList : Int -> (a -> a) -> List a -> List a
changeItemInList idToUpdate itemUpdate someList =
  List.indexedMap (setItemAtIndex idToUpdate itemUpdate) someList
  
-- apply itemUpdate function if index matches idToUpdate
setItemAtIndex : Int -> (a -> a) -> Int -> a -> a
setItemAtIndex idToUpdate itemUpdate index a =
  if (idToUpdate == index) then
itemUpdate a
  else
a

{- view renders a button to add a counter + list of counters from model -}
view : Model -> Html Msg
view model =
  let
countersHtml =
  List.indexedMap counterView model
  in
div []
  [ button [ onClick AddCounter ] [ text "Add counter" ]
  , div [ style [("display","flex")] ]
  countersHtml
  ]

-- helper to render a counter, we need the index to include in message
counterView : Int -> CounterValue -> Html Msg
counterView index counterValue =
  CounterView.view (Increment index) (Decrement index) counterValue

A note here: Looping over the entire list of counters to update one single 
counter, with the update helpers, feels inefficient. An alternative is to 
use Dict, and get the item to update. But then each branch in the update is 
around 10 instead of 1 line, because get returns a Maybe type, and we have 
to factor this in.

The separated CounterView.elm module is:
module CounterView exposing (..)
import Html exposing (Html)

{- our view function takes 3 arguments:
  1. some Increment message (of any type, therefore in lowercase)
  2. some decrement message
  3. an Int with the counter value to display
The output is Html + the msg type of the 2 input messages.
So our view function, and this module do not own the message type.
Could have put the static parts (the 2 messages) in a config record, like 
the elm-sortable-table,
but for just 2 input variables, a record feels like overkill
-}
view : msg -> msg -> Int -> Html msg
view incrementMsg decrementMsg counterValue =
  div [ style [("flex","0 0 32px")]]
[ button [ onClick incrementMsg ] [ text "+" ]
, div [] [ text (toString counterValue) ]
, button [ onClick decrementMsg ] [ text "-" ]
]

Note here: The API of this view function is msg -> msg -> Int, so the 
importing module needs to know to pass these three variables + what they 
are supposed to do + what type they should be.

-- 
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: Do the counters in the Guide teach us a wrong scaling approach?

[Wouter In t Velt]

>
> I would love to know how to do this!
> Can anyone point me to a brain-dead-simple practical and working example 
> for a non-expert Elm user like myself?

OK, so here is my take at an alternative multiple counters approach.
{- Model needs to hold a list of counter values
Any counter in the list is simply identified by its index
-}
type alias Model =
  List CounterValue
  
type alias CounterValue =
  Int

-- the defaultmodel is simply an empty list
defaultModel : Model
defaultModel = 
  []

{- Original Msg type needs to be expanded to include the ID of the counter
to update. So our update function knows which counter to change.
We could have done something like a nested Msg structure.
But no need to make things more complicated than needed, so we keep things 
simple 
-}
type Msg =
  AddCounter
  | Increment CounterId
  | Decrement CounterId
  
type alias CounterId =
  Int

{- Update uses helper function to update the right counter (indicated by 
index from Msg)
-}
update : Msg -> Model -> Model
update msg model =
  case msg of

AddCounter ->
  -- add new counter with default value of zero to our list
  model ++ [ 0 ]
  
Increment counterId ->
  -- invoke helper to increment item at index
  changeItemInList counterId (\item -> item + 1) model

Decrement counterId ->
  -- invoke helper to decrement item at index
  changeItemInList counterId (\item -> item - 1) model

-- helper to update an item in any list, applying a function to item at 
index
changeItemInList : Int -> (a -> a) -> List a -> List a
changeItemInList idToUpdate itemUpdate someList =
  List.indexedMap (setItemAtIndex idToUpdate itemUpdate) someList
  
-- apply itemUpdate function if index matches idToUpdate
setItemAtIndex : Int -> (a -> a) -> Int -> a -> a
setItemAtIndex idToUpdate itemUpdate index a =
  if (idToUpdate == index) then
itemUpdate a
  else
a

{- view renders a button to add a counter + list of counters from model -}
view : Model -> Html Msg
view model =
  let
countersHtml =
  List.indexedMap counterView model
  in
div []
  [ button [ onClick AddCounter ] [ text "Add counter" ]
  , div [ style [("display","flex")] ]
  countersHtml
  ]

-- helper to render a counter, we need the index to include in message
counterView : Int -> CounterValue -> Html Msg
counterView index counterValue =
  CounterView.view (Increment index) (Decrement index) counterValue

A note here: Looping over the entire list of counters to update one single 
counter, with the update helpers, feels inefficient. An alternative is to 
use Dict, and get the item to update. But then each branch in the update is 
around 10 instead of 1 line, because get returns a Maybe type, and we have 
to factor this in.

The separated CounterView.elm module is:
module CounterView exposing (..)
import Html exposing (Html)

{- our view function takes 3 arguments:
  1. some Increment message (of any type, therefore in lowercase)
  2. some decrement message
  3. an Int with the counter value to display
The output is Html + the msg type of the 2 input messages.
So our view function, and this module do not own the message type.
Could have put the static parts (the 2 messages) in a config record, like 
the elm-sortable-table,
but for just 2 input variables, a record feels like overkill
-}
view : msg -> msg -> Int -> Html msg
view incrementMsg decrementMsg counterValue =
  div [ style [("flex","0 0 32px")]]
[ button [ onClick incrementMsg ] [ text "+" ]
, div [] [ text (toString counterValue) ]
, button [ onClick decrementMsg ] [ text "-" ]
]

Note here: The API of this view function is msg -> msg -> Int, so the 
importing module needs to know to pass these three variables + what they 
are supposed to do + what type they should be.

-- 
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: Do the counters in the Guide teach us a wrong scaling approach?

[Wouter In t Velt]

>
> I would love to know how to do this!
> Can anyone point me to a brain-dead-simple practical and working example 
> for a non-expert Elm user like myself?


OK, so here is my take at an alternative multiple counters approach.
First, putting everything in one (monolithic) module:

import Html exposing (Html, div, button, text)
import Html.App exposing (beginnerProgram)
import Html.Events exposing (onClick)
import Html.Attributes exposing (style)

import CounterView -- our separated view function

main =
  beginnerProgram 
{ model = defaultModel
, view = view
, update = update 
}

{- Model needs to hold a list of counter values
For clarity, we define an alias for CounterValue
The uid of the original counter list Model is not really needed
Any counter in the list is simply identified by its index
-}
type alias Model =
  List CounterValue
  
type alias CounterValue =
  Int

-- the defaultmodel is simply an empty list
defaultModel : Model
defaultModel = 
  []

{- Original Msg type needs to be expanded to include the ID of the counter
to update. So our update function knows which counter to change.
We could have done something like a nested Msg structure:

type alias Msg =
  AddCounter
  | ForCounter CounterId CounterMsg
  
type alias CounterMsg =
  Increment
  | Decrement
  
But no need to make things more complicated than needed, so we keep things 
simple
-}
type Msg =
  AddCounter
  | Increment CounterId
  | Decrement CounterId
  
type alias CounterId =
  Int


{- Update takes the message and update model (duh ;), 
using a helper function to update the right counter (indicated by index from 
Msg)
in its list
-}
update : Msg -> Model -> Model
update msg model =
  case msg of

AddCounter ->
  -- add new counter with default value of zero to our list
  model ++ [ 0 ]
  
Increment counterId ->
  -- invoke helper to increment item at index
  changeItemInList counterId (\item -> item + 1) model

Decrement counterId ->
  -- invoke helper to decrement item at index
  changeItemInList counterId (\item -> item - 1) model


-- helper to update an item in any list, applying a function to item at 
index
changeItemInList : Int -> (a -> a) -> List a -> List a
changeItemInList idToUpdate itemUpdate someList =
  List.indexedMap (setItemAtIndex idToUpdate itemUpdate) someList
  
-- apply itemUpdate function if index matches idToUpdate
setItemAtIndex : Int -> (a -> a) -> Int -> a -> a
setItemAtIndex idToUpdate itemUpdate index a =
  if (idToUpdate == index) then
itemUpdate a
  else
a


{- view renders a button to add a counter + list of counters from model
-}
view : Model -> Html Msg
view model =
  let
countersHtml =
  List.indexedMap counterView model
  in
div []
  [ button [ onClick AddCounter ] [ text "Add counter" ]
  , div [ style [("display","flex")] ]
  countersHtml
  ]

-- helper to render a counter, we need the index to include in message
counterView : Int -> CounterValue -> Html Msg
counterView index counterValue =
  CounterView.view (Increment index) (Decrement index) counterValue

A note here:

   - Looping over the entire list of counters to update one single counter, 
   with the update helpers, feels inefficient. An alternative is to use Dict, 
   and get the item to update. But then each branch in the update is around 10 
   instead of 1 line, because get returns a Maybe type, and we have to factor 
   this in.

The separated CounterView.elm module is:
module CounterView exposing (..)

import Html exposing (Html)

{- our view function takes 3 arguments:
  1. some Increment message (of any type, therefore in lowercase)
  2. some decrement message
  3. an Int with the counter value to display

The output is Html + the msg type of the 2 input messages.
So our view function, and this module do not own the message type.

Could have put the static parts (the 2 messages) in a config record, like 
the elm-sortable-table,
but for just 2 input variables, a record feels like overkill
-}
view : msg -> msg -> Int -> Html msg
view incrementMsg decrementMsg counterValue =
  div [ style [("flex","0 0 32px")]]
[ button [ onClick incrementMsg ] [ text "+" ]
, div [] [ text (toString counterValue) ]
, button [ onClick decrementMsg ] [ text "-" ]
]


Note here:

   - The API of this view function is msg -> msg -> Int, so the importing 
   module needs to know to pass these three variables + what they are supposed 
   to do + what type they should be.
   

-- 
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: Do the counters in the Guide teach us a wrong scaling approach?

[Wouter In t Velt]

@Erik Lott, did you mean:

view : Msg -> Msg -> Int -> Html Msg

Or did I miss something?

@Peter Damoc, yeah the flat solution would be simpler (I actually did do a flat 
counter list before separating out the CounterView ;).

-- 
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] Functional programming, or why should I use Elm instead of vanilla javaScript?

[Wouter In t Velt]

This react-conf 2016 video on Elm 
 (which was when I first heard 
of Elm) is a great explanation of the many things which are possible in 
javascript, but not necesserily good.

Javascript is like an irresponsible parent. You can do pretty much whatever 
you like (which is great), but that includes stuff that is really bad for 
your own future and for the rest of the world.

Elm is like a strict parent. It forces you to work in a disciplined way, 
but you (and your users!) will be really thankful later.


-- 
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: Do the counters in the Guide teach us a wrong scaling approach?

[Wouter In t Velt]

Thanks for the feedback folks. Really helpful and got me thinking. Will 
definitely dive into the links @NickH shared.
And @ErikLott's example of a multi-page SPA (forgive the oxymoron) was also 
helpful. This is one of the places I run into issues: my top level update 
is already huge and growing.

Also, I take the advice to heart to share/ ask questions on concrete and 
practical cases.

That said, for me, scaling Elm remains a struggle, and I find it hard to 
pinpoint specific use cases to share here as a question.

I really believe it when more experienced people say that elm scales, I am 
just struggling with the "how".

It's like I keep falling whenever I try to ride this new elm-bike. 
And I keep hearing from others that they just get up and go and don't fall,
so I should also just go and don't fall, or be very specific at which point 
in my process I fall off my bike.
(Sorry if the analogy is somewhat far fetched).

This was different when I learned react some years ago.
And I was just wondering why it was such a different experience.

And it occurred to me that some of the "why does everyone insist on asking 
about components"-meme may have been triggered because the counter example 
is a very prominent (if not the most prominent) example in the Guide.

I agree with Nick H that adding more examples is probably more helpful than 
rewriting existing ones. 

Back in the days, when I learned react, I found this page 
 very 
helpful. It explains how to structure in react. What state is, and where to 
put it.
Maybe a similar "thinking in elm" page will 
a) help folks like me learn how to structure their apps in elm and 
b) reduce unwanted/ vague questions about components on this forum.

-- 
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] Should I have a CSS file for my made-with-Elm web app?

[Wouter In t Velt]

What works for me is:

   - Separate CSS file for static styling and basic UI animations, so I 
   only need to add class attributes in view functions.
  - Layout, fonts, hover and focused states etc etc all go in css file.
  - So e.g. if I want to make give a "selected" element in a list a 
  different background-color, I use elm to apply a class of e.g. 
  "item--selected", and use css to define the styling.
  - Basic UI animations: E.g. I have a dropdown menu for which appears 
  if a button is clicked. This is handled completely in css, using the 
:focus 
  state of of the button to unhide the dropdown.
   - Do transitions and more complicated animations directly in elm.
  - Unfortunately, css can only handle basic animations/ transitions.
  - E.g. for drag and drop, do positioning directly in elm (but I keep 
  the styling in css)
   
I use webpack for development, but I have not yet found a way to 
"automatically" import the right css files needed.

-- 
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: Basic behavioral composition

[Wouter In t Velt]

Thank you for this very clear and concise description @debois!

Coming from React+Flux, I've followed much of the discussions on 
child-parent communication, components etcetera, but I found it really hard 
to scale in elm.
The "everything is a component" from react is a hard habit to break, and 
although I understood (+ learned the hard way) that components are not the 
way to go in elm, it wasn't really clear to me what the right (or better) 
way is.

Your post is a very helpful guideline, thanks!

-- 
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: Modeling a domain with complex data access constraints

[Wouter In t Velt]

Hi Spencer, In an Elm app I am building I ran into similar challenges.
The principles which work well for me in model design:

   - Flat is better than nested (for relational stuff, such as your courses)
   - One source of truth = a normalized model without duplication of data
   - Connect data for viewing in your views.

So I would "normalize" your model as below:

   - Put sessions in your model at top level: you want to access the 
   sessions directly
   - For parent-child-like relations (like course-session), only include 
   the parent Id in the child.

E.g. Course type does not need a list of sessions: this info is stored in 
the sessions (which also contain course Id).

In your views, retrieve from your model the info that you need, e.g. 
getting the names of the tutors.

I would personally not qualify a UserId of someone else as something that 
the user is not supposed to see: it is a data Id for connecting 2 records.
Still, if you really want the user not to see Id of who is enrolled, you 
can include that in your model as a Registration type.

The real trick is probably to selectively populate this model in 
client-server communication: make your API only provide those Users, 
Sessions, Courses to which the particular user has access.


type alias Model =
  { me : Maybe UserId
  , users : Dict UserId User
  , courses : Dict CourseId Course
  , sessions : Dict SessionId Session
  }

type alias User =
  { name : String
  , id : UserId
  , role : UserRole
  }
  
type UserRole =
  Admin
  | Faculty
  | Student

type alias Course =
  { id : CourseId
  , name : String
  , instructor : UserId
  }

type alias Session =
  { id : SessionId
  , course : CourseId
  , time : Date
  , tutor : UserId
  , location : String
  , registration : Registration
  }

type Registration = 
  Available
  | Registered
  | RegisteredBy UserId


-- 
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: Modeling cross-references

[Wouter In t Velt]

>
> On Sunday, September 25, 2016 at 8:54:50 AM UTC+10, Eric G wrote:
>>
>> - Is it better to use Dicts as the basic 'table' structure, if frequently 
>> rendering lists of items filtered and sorted in various ways? In short, is 
>> it better to convert a `List (ID, Item)` to a Dict for finding items, or 
>> convert a `Dict ID Item` to a List for rendering them?  I kind of am 
>> leaning towards `List (ID, Item)` as the persistent data structure esp. for 
>> data that is frequently rendered in lists, but would really appreciate 
>> hearing what peoples' actual experiences have been.
>>
>
I find myself using Lists most of the time. Probably because:
- Lists is sort of entry level (consider myself still beginner in Elm) - 
all the tutorials are in Elm
- I find code for List manipulation easier to understand/ read.
- Lists are a lot easier to manipulate (especially sorting and filtering), 
which is what happens a lot in my code
- Many of the the lists I work with are not very long (so no performance 
need to switch to Dict)
 

> - How are people modelling so-called 'value types' ?  For example in the 
>> Albums/Artists if you had a `genre` type assigned to Albums. The genre 
>> types change infrequently, but perhaps the application still needs some 
>> kind of user interface to change them, which suggests they should be stored 
>> as data, e.g. `List (ID, String)`, with no special behavioral significance 
>> to the app.  On the other hand, in some cases you have value types that 
>> *do* have behavioral significance, such as e.g. User Roles, and it is 
>> tempting to want to have these map to Elm types instead of strings when you 
>> `case` on them in view and update. But this means duplication of server- 
>> and/or datastore- side data, and you still have to map your Elm types back 
>> to IDs.
>>
>
I think you already answered this yourself :) The genre-like data, I put in 
my model as a separate List (ID, String). They are a List because for the 
program it does not matter how many genres they are, and what their names 
are. If the app has logic to deal with genres (e.g. filters), it will also 
work if the list has more items.

User Roles is a specific case: because it DOES matter how many options 
there are + your program needs logic for each role, Elm types do make 
sense. I wouldn't worry about the duplication: ALL server side data sent to 
client will of course be stored = duplicated there. And it is not uncommon 
to transform server data into different types at client side.

-- 
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: Confused by error (inline function, >, tagged type)

[Wouter In t Velt]

It looks like the error you get is because you redefine the '>' function by 
using the same function:

   - You redefine '>' to take 2 DropsPerSecond types
   - Inside this function you want to use the "old" '>' function to compare 
   2 Floats

The compiler - I think - is ahead of you: it uses your new definition of 
'>', taking the 2 DropsPerSecond.
And gives you an error because you are passing it something else.

In my (limited) experience, strong typing did not pay off, and I stick to 
type aliases mostly. For strong typing, you basically need to re-define any 
core operation which would otherwise just be available. The chance of 
making mistakes in these outweigh (for me at least) the benefits of extreme 
type safety.

-- 
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] Does CSS model the right problem?

[Wouter In t Velt]

Gss and Slalom are very impressive indeed! Would be great if to use with Elm.
Thanks for sharing Peter and Duane!

-- 
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: Routing, authentication etc. still on my 3rd Elm project.

[Wouter In t Velt]

Very useful to read your experiences with Elm. I am in a more-or-less 
similar point on the learning curve.
Small aside: The Elm Exts (extentions) package has a simple function called 
catMaybes to filter out Nothings:
catMaybes : List (Maybe a) -> List a

Link here: 
http://package.elm-lang.org/packages/krisajenkins/elm-exts/25.13.0/Exts-Maybe#catMaybes

-- 
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: Correct use of port subscriptions in a submodule reused multiple times?

[Wouter In t Velt]

In your design, the port has a 1-to-1 connection to the Part.
The port does not communicate for which Part the incoming message is 
intended, because it "expects" that their is only 1 Part.

Your batch function in the subscriptions in the Group.elm passes on the 
port message on to all your Parts.
Your port receives one message of type `PortMsg (Some, Values)`.
The Group subscription function effectively turns this into 10 messages of 
type `PartMsg 0 PortMsg (Some, Values)` etcetera.
And passes each on Group update function.
So all parts respond to the one message.

You could:

   - refactor your port, to provide also an Int id of the intended Part to 
   receive the message
   - subscribe to this port ONLY in Group
   - that would also mean you need to change code in JavaScript-land, to 
   provide the Id when sending info to Elm

Or:

   - store an `activePart: Int`  in your Group model, so your Group update 
   knows to which single Part the message should go
   - subscribe to the (unchanged) port in your Group subscriptions only 
   (without bundling the subscriptions of each of the Parts)

Or other options.
But that depends very much on what you want to achieve. The terms 'Part' 
 and 'Group' are quite generic, and it is unknown what happens at the other 
end of the port.
Maybe you could elaborate on what you want to achieve?


-- 
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: Can I use css animations normally in elm?

[Wouter In t Velt]

I have some experience in this, and for basic stuff you can use css. And it 
keeps your elm code nicely focused on state, without complexity of having 
to manage state transitions inside state.
e.g. for displaying and hiding a sidebar-menu which slides in from the 
left, or a dropdown-menu, something like:

   - have an menuIsOpen flag in your model,
   - and in your view add a class "open" to your menu
   - and in your css have something like this:

.sidebar {
  position: absolute;
  will-change: transform;
  transform: translateX(-102%);
  transition: transform 400ms;
}

.sidebar.open {
  transform: translateX(0%);
}

.dropdown {
  position: absolute;
  opacity: 0;
  will-change: opacity;
  pointer-events: none;
  transition: opacity 400ms;
}
.dropdown.open {
 opacity: 1;
 pointer-events: auto;
}

What happens here is that elm will render the new state, and after that, 
css animation transitions to the new state on screen.

However, this only works for items that you can put/ which are in the DOM 
both before and after the animation. And you cannot use "display: none" to 
hide items (because css does not animate that). For more advanced 
animations:

   - Adding a new item to a list (typically the new item is not in the DOM 
   before it is added)
   - Removing items from a list (the removed item is typically not rendered 
   after the removal).
   - Functions or logic that should be available only after the transition 
   has completed. (e.g. first enlarge some square, and only afterwards display 
   contents of the square)
   - Page transitions from one page to the next.
   - Reversible animations: e.g. if the users clicks the "close" button 
   midway in the opening transition.

There are ways to get more done with css, but I always need more 
elm-trickery too. I find that doing more complex animations fully in elm 
gives me the most maintainable 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] Structure for large Elm apps

[Wouter In t Velt]

Op vrijdag 21 oktober 2016 21:01:29 UTC+2 schreef Ed Ilyin:
>
> Can you, please, provide an example?
>

In a SPA I am developing, I use a structure like:
Helpers.elm
Helpers -- folder with more helpers
  Nav.elm -- helpers for navigation
  Exam.elm -- helpers for updating the exam
  Summaries.elm -- helpers (for view) to create a summary string from 
details
Main.elm
Model.elm
Msg.elm
Route.elm -- with routes the user can navigate to
Types.elm -- details of the stuff in the model
Update.elm
View.elm
Views -- folder with elm file per page, imported by view.elm
  Today.elm
  Exams.elm
  EditExam.elm
  PickExamDate.elm

Whenever I create a new page (let's say a page to see the entire calendar), 
I usually modify stuff in the following order:

   - add a route in Route.elm
   - add a type in Types.elm (if needed)
   - modify my Msg (if needed)
   - modify update.elm, 
   - add another view file in the view folder, 
   - and import this file in my main view.elm file.

Flat helps me to only change what is needed: Often a new page I want is 
just another view of the same data. So I do not need a new model, and I do 
not need to change the model, I only need a new view function. And a very 
simple change to the update function, to enable navigating to the new page.

I was very much inspired by the Time Tracker SPA (see here 
), which may also be a good place 
to look at a flat structure.

Previously, I had one exam component, with its own model, update and view. 
Each exam had a list of dates.
When I wanted to create a page that showed a calendar, and for each date, 
show the exams for which the user plans to study, I realised my component 
structure broke down.
-- before (nested)

type alias Model =
  { exams : List Exam }

type alias Exam =
  { subject : String
  , studyDates : List Date
  }

-- now (flat)

type alias Model =
  { exams : List Exam
  , studyDates : List StudyDate
  }

type alias Exam =
  { id : Int
  , subject : String
  }

type alias StudyDate =
  { studyDate : Date
  , exam : Int -- id only
  }

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.

Re: [elm-discuss] Proposal: rename foldl til foldLeft and foldr to foldRight

[Wouter In t Velt]

Op dinsdag 25 oktober 2016 02:20:29 UTC+2 schreef Max Goldstein:
>
> Changing things makes upgrading harder, invalidates old code, and gives 
> the larger community the impression that Elm is not stable.
>

The question is whether different naming for "foldl" and "foldr" would 
bring enough benefits to be worth all these (temporary) drawbacks.
So:

   - "foldLeft" and "foldRight" are easier to keep apart/ more readable - 
   regardless of someone's previous language
   - "reduce" and ("foldr" or nothing or something else) would be more 
   familiar to people coming from JS (and possibly other languages too)

My own background is JS, so "reduce" is familiar. 
But at the same time, I use "foldl" way more often in Elm than I ever used 
"reduce" in JS, and in very different ways.

What I see as a structural drawback to "foldLeft" and "foldRight" is the 
length of the function names: shorter names are better, and (for me at 
least) the extra characters in the function names do not give me any 
relevant info or benefits.
90% of the time I use any fold, my output is the same in both directions. 
(like .sum or .maximum etcetera). 
I have never used "foldr" (yet).

-- 
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] Proposal: Rename case..of -> match..with

[Wouter In t Velt]

Personally I prefer "case ... of"

I find it easier to read: "(in) case [this thing] (is) of [this pattern], (do) 
[this function]".
It is a variant of the "if ... then ... else .." syntax.

To me, "match ... with" would be less easy to read (although other languages 
apparently use it), but also more confusing: "match [this] with [that]" also 
suggests "make [this] equal to [that]"

-- 
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] Structure for large Elm apps

[Wouter In t Velt]

+1 for the "better flat than nested " approach.
I think it was the second elm town podcast where Brian admitted that he 
actually regretted his post.

>From personal experience (admittedly limited) I definitely agree to the "flat 
>is better than nested". Having one update function with helpers, and not 
>having any components with local state has made debugging at least 10x faster 
>for me.

Adding features like an undo function was way easier with a flat structure.

-- 
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: Naming functions

[Wouter In t Velt]

Op maandag 24 oktober 2016 13:18:59 UTC+2 schreef Lars Jacobsson:
>
> Any thinking going out there on around naming conventions OOP vs 
> functional? I'd be grateful for any input on this matter of life or death!
>

I always try to keep my naming conventions close to the Core functions.
E.g. in my Elm app, I have functions similar to yours. They are called 
listUpdate and listInsert with the following signatures:

listUpdate : Int -> (RecordWithID a -> RecordWithID a) -> List (RecordWithID 
a) -> List (RecordWithID a)
listUpdate index updatefunction list =

listInsert : Int -> RecordWithID a -> List (RecordWithID a) -> List (
RecordWithID a)
listInsert index newRecord list =

type alias RecordWithID a = { a | id : Int }

The names were inspired by Dict.insert and Dict.update, which were the 
closest to what I was looking for.

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

[Wouter In t Velt]

Op maandag 14 november 2016 02:24:16 UTC+1 schreef Witold Szczerba:
>
> Can you provide some real-life example of "moving away from components"? 
> That could be helpful…
>

Sure. My background is in React, where everything there is components too.
No examples of my own to share just yet. My app is very much "work in 
progress", and not yet clean enough to share I am afraid.

In the first version of my app (to plan homework), I would have e.g. an 
EditExam.elm file that contained its own Model, init, update, Msg and view.
And in my main.elm, I would import this module and integrate each of these 
into the main Model, init etc.
So basically, EditExam.elm was a "component". With the purpose of 
displaying an Exam, and allowing user to edit details.

When moving away from components, I created top-level files in my root 
directory:

   - Model.elm
   - Msg.elm
   - Update.elm
   - View.elm
   - Main.elm (which imports all of the above).

I copied the code bits from the component into each of these files. So for 
example:
type alias Model =
  { ...
  , exams : List Exam
  , currentExam : Exam
  }

type alias Exam =
  { subject : String
  , ...
  }

So the Exam type is the Model from the old EditExam.elm file.
Did the same for init, Msg, update, and view.

A (larger) real-life example that I use as a reference is the time-tracker 
SPA (here on github ). Which is a 
project as part of a DailyDrip  series.

A very good explanation (with simple examples) of non-component scaling in 
Elm is in the Official Guide here .
That explanation helped me a lot, along with the video's on sortable table 
linked there.

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.

[elm-discuss] Re: Using Navigation - is Events.onWithOptions required?

[Wouter In t Velt]

Op woensdag 23 november 2016 23:52:54 UTC+1 schreef Brian Marick:
>
> So I suspect I’m doing something wrong. Am I?
>

Not wrong, I guess, but it is kind of a peculiar setup.

I also use elm-lang/navigation, and never ran into this issue.
After checking my code:

   - Either I use an `a [ href "#/path/location ]` to let the url-parser 
   navigate when the user clicks the link.
   - Or I use `button [ onClick (NavigateTo NewLocation) ]` to go to the 
   update function.

(urlUpdate and update are wired so that navigation instructions can come in 
through either function).

So it seems kind of double to use both the href and the onClick on the same 
element to do navigation.

-- 
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] What Elm needs to move forward

[Wouter In t Velt]

Maybe the Elm Weekly newsletter, the ElmTown podcast, and the remote 
meetups would be useful additions to the http://elm-lang.org/community page?

-- 
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: How to use Navigation library

[Wouter In t Velt]

Thank you for the explanation Erik! With the upgrade to 0.18 and the 
changes in navigation, I was wondering which route (pun intended) to follow 
with the upgrade. Not sure I follow completely though.

In option 1, could you deal with redirect-like scenario's inside the SPA?
Like

   1. user is on the "/apples" page, showing all available apples.
   2. user types "/apples/234"  in the url-bar
   3. there happens to be no such apple
   4. I want the user to stay on the "/apples" page, and get a message like 
   "this apple is forbidden fruit"
   5. at this point, I would want the url-bar to also say "/apples"

Can this work with option 1? Or is this only possible with option 2?

-- 
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: Dynamic Unsubscribing to subscriptions?

[Wouter In t Velt]

Your subscriptions also take model as input, so you could do something like 
this:

subscriptions : Model -> Sub Msg
subscriptions model =
  if model.followMouse then
Mouse.moves MyMsg
  else
Sub.none

You could look at the drag-and-drop example elm-lang.org examples to see 
how conditional subscriptions work.

-- 
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: Passing properties as arguments to messages?

[Wouter In t Velt]

PS: the function definition should not be capitalized, but should be called 
"animateProperty" of course

-- 
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: Passing properties as arguments to messages?

[Wouter In t Velt]

There is a way to make it work, but it will be a lot more verbose/ ugly/ 
overengineered. Your signature would need to look something like this:

AnimateProperty : Model -> (Model -> Style) -> (Style -> Model -> Model) -> 
Msg -> (Model, Msg)
AnimateProperty = model funcToExtractStyle funcToUpdateStyle animMsg =
  ...

-- call this as follows
(newModel, newCmd) = 
  animateProperty 
model 
(.answerTextStyle)
(\newStyle a -> { a | answerTextStyle = newStyle } )

And it will only work if all your properties are of the same type.
And if they are all of the same type, you would be better off to put all 
your styles in a `Dict`, which would make the `AnimateProperty` a lot 
cleaner.

-- 
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] Proposed addition for Task package

[Wouter In t Velt]

Op dinsdag 22 november 2016 13:47:55 UTC+1 schreef Charlie Koster:
>
> I respectfully disagree. Depending on the application, this either may not 
> be possible or would be a terrible code smell. I honestly think the above 
> suggestion would be worse than chaining another Cmd msg. Sending another 
> Cmd msg is clean and follows the Elm architecture.
>
I agree it depends on the application. Sometimes `Cmd msg` would be better, 
sometimes it would be worse. `Cmd msg` follows the Elm architecture, but I 
have seen terrible bugs being introduced by improper use, caused by Cmd 
messages being created based on model state A, and because of race 
conditions (e.g. fetch results coming in in the meantime), the call that 
the elm runtime made to the update function was with model state B. (when 
using Cmd, there is NO guarantee about the state of the model that the 
runtime will pass to the update function).

When I was beginning to learn Elm, this function was not around, and it 
forced me to learn more about TEA, Tasks, runtime etcetera.
Which in hindsight was IMHO a good thing.

-- 
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] Proposed addition for Task package

[Wouter In t Velt]

My 2c:  I kind of like it that there is NOT such a function in the core.
Because it *prevents me from grabbing it when I really shouldn't*.

Especially if the `Cmd` has no side effects, it is better to do a recursive 
call to the `update` function, or better yet: call the function that your 
command would call, if it had been passed to the elm runtime.

Many of the names of the messages in the example suggest that creating a 
`Cmd msg` is not the best solution.

The only exception I can think of where it is useful is using 
`Process.sleep` to force a timeout.

-- 
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] Proposed addition for Task package

[Wouter In t Velt]

Op dinsdag 22 november 2016 14:49:47 UTC+1 schreef Charlie Koster:
>
> My assumption is a race condition here wouldn't be possible since calling 
> `sendMsg MyMsg` is a synchronous action
>

I have tried it out in elm-lang.org/try, which suggests that it is 
asynchronous, in a simple setup
- button that sends a DoStuff message
- in update, the DoStuff branch outputs DoMore
- update also logs all messages
- the setup also contains a basic subscription to Time, with a Tick every 
10ms

The log then shows that between the DoStuff message and the DoMore message, 
a Tick message comes in.
This is an extreme example, I admit, but with subscriptions to server 
messages, mouseovers etc, there is no telling when messages come in.
So my takeaway was: if you want something done synchronously, handle it 
inside a single update cycle.

If the community agrees that using Cmd Msg as you suggest is a valid 
pattern with valid use cases, then the (simple) helper would be a useful 
addition to a Task (or Platform? or Platform.cmd) package.

The fact that we do not agree on this, makes it an interesting discussion 
here.
Where do others stand on this?

-- 
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: Passing properties as arguments to messages?

[Wouter In t Velt]

Op dinsdag 22 november 2016 15:55:25 UTC+1 schreef Rex van der Spuy:
>
> But, can anyone explain why Elm doesn't let us do this?
>

My impression is that it has to do with the enforced strong typing and type 
safety of elm.

A record is intended for key-value type info where each value could be of a 
different type.
And elm's greatness requires that elm always knows the type it is working 
on.
Dynamic typing for records (which javascript does allow for objects) would 
break this guarantee.

So with a record, you get the flexibility that each field could be whatever 
type, but you lose the dynamicness (is that even a word?) of the keys.
With Dict, it is the other way around. You can get a value by supplying a 
dynamic key, but all values in the Dict must be of the same type.

-- 
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] Proposed addition for Task package

[Wouter In t Velt]

For those interested: here is the example I refered to:
import Html exposing (..)
import Html.Events exposing (onClick)
import Time exposing (Time, second)
import Task

main =
  Html.program
{ init = init
, view = view
, update = update
, subscriptions = subscriptions
}

-- MODEL
type alias Model = { msgs : List String, timerOn : Bool }

init : (Model, Cmd Msg)
init =
  { msgs = []
  , timerOn = True
  } ! []

-- UPDATE
type Msg
  = Tick Time | DoStuff | DoMore


update : Msg -> Model -> (Model, Cmd Msg)
update msg model =
  case msg of
Tick newTime ->
  { msgs = toString msg :: model.msgs
  , timerOn = True
  } ! []
  
DoStuff ->
  { model | msgs = toString msg :: model.msgs }
  ! [ send DoMore ]
  
DoMore ->
  { model | msgs = toString msg :: model.msgs, timerOn = False } ! []
  
  
send : msg -> Cmd msg
send msg =
  Task.succeed msg
  |> Task.perform identity


-- SUBSCRIPTIONS
subscriptions : Model -> Sub Msg
subscriptions model =
  if model.timerOn then
Time.every 10 Tick
  else
Sub.none

-- VIEW
view : Model -> Html Msg
view model =
  div []
[ button [ onClick DoStuff ] [ text "click" ] 
, ul []
  <| List.map itemView model.msgs
]

itemView : String -> Html Msg
itemView string =
  li [] [ text string ]


-- 
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] What Elm needs to move forward

[Wouter In t Velt]

My learning curve has been similar to what Oliver describes.

IMHO, there still a large gap between The Official Guide and the community 
platforms, that needs to be filled. 
The Official Guide is a great doc, but it has very few examples, and mostly 
entry-level and small. 
Outside the guide, the mailing list and slack channels are great for 
instant Q and small code snippets.
Beyond that, it is a world of “anyone can share anything anywhere”. 

Don’t get me wrong, there is very good elm-stuff out there, and I am very 
grateful for the effort that the community puts in examples, blogs, confs 
etcetera.
I just wish there were a sharing platform in-between.

For libraries, the processes and publication around packages are very 
useful.
But not everything is a library.

It would be useful if there was some sort of “community endorsed” examples 
archive, with some vetting process (maybe voting).
These could be small (like a dropdown, sortable table, drag-and-drop 
reorder list, sidebar, port to do Firebase authentication and database 
connections etc etc), or larger, like a SPA.
With not just code, but also written in a Guide-like way.

I lack the skills to set up something like that, but would be more than 
happy to contribute with code examples and descriptions.

-- 
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: How to use Navigation library

[Wouter In t Velt]

Thanks Erik, I think I got it.
In case of not found, I prefer the not found message over not found page.
With your explanations in this thread, I'll probably be able to do that.
If not, I'll be back here :)

-- 
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 post: feedback requested

[Wouter In t Velt]

Over on Medium, I've written an article to share some beginner/ 
intermediate experiences in Elm.
About extracting helper functions.
https://medium.com/@wintvelt/making-elm-code-more-compact-and-more-readable-935067f81829

Any feedback (here on over on medium) would be highly appreciated!
Thanks.

-- 
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] The Elm Architecture and Html.beginnerProgram

[Wouter In t Velt]

The `model` function is called only once, when your app is started.

Then your `view` function is called, to render the model to the DOM.

After that, every time your `view` function produces and `Msg`, your `update` 
function is called, and the resulting model is passed on to another call of 
your `view`.

I have never really cared for what goes on "under the hood" of the elm runtime 
that handles all this.

What is your use case that triggers your interest in this?

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

[Wouter In t Velt]

Thank you all for clearing that up.
I discovered the elm-decode-pipeline through this, so that's also valuable.

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

[elm-discuss] Re: Ho to work with the DOM of element where Elm is 'embed'ed.

[Wouter In t Velt]

I tried this once with the idea to have some sort of "Elm is initializing" 
static HTML, to be replaced after my elm app loaded and ran.
So for me this behavior wasn't what I needed at the time.
(By now my elm app loads and runs in 1600ms first load, and 250ms with 
caching, so fortunately don't need the Loading screen anymore)

-- 
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] Ho to work with the DOM of element where Elm is 'embed'ed.

[Wouter In t Velt]

I tried that in 0.17, and the embedded elm stuff was placed after the last 
existing child of the node where I embedded elm.

So:


  
  
... Elm stuff
  


-- 
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] Issue a command after view update

[Wouter In t Velt]

Op vrijdag 18 november 2016 11:22:51 UTC+1 schreef Tim Bezhashvyly:
>
> That's the issue. By the time load command is sent the HTML markup must be 
> already present at the page. 
>

I am not to familiar with Google maps integration, but it looks like the 
actual update of the map in the DOM is done in javascript, not in Elm.
The value is sent to elm and stored in the model, but elm doesn't really do 
anything with this data.

I suspect that the Time command won't work, because it is made immediately, 
and gives results immediately. It does not wait for DOM to be rendered. So 
probably javascript will give you a (not so helpful) error.

If you want to make sure that something is in the DOM, you could look 
at 
http://package.elm-lang.org/packages/elm-lang/animation-frame/1.0.1/AnimationFrame.
Which works with subscriptions. And feeds to your model only after every 
DOM update.
This would require a bit more to setup. Something like:

   - add a variable like `mapState` in the model that has the map state, 
   e.g. `type MapState = NoMapHere | Loading | Rendered`
   - in your init function, set the value to `mapState = Loading`
   - in your subscriptions, subscribe to `AnimationFrame.times` only if 
   your mapState is `Loading`, and let it produce a `Tick`
   - in your update function, your `Tick` update should a) do `mapState = 
   Rendered` (canceling your subscription) and b) send the loadMap command out

With a button, it is easier: if you render the button together with your 
gmap, you can be sure that the load is only called if the gmap is rendered. 
The button can only be clicked if it is in the DOM, which means the map 
must also be in the DOM.

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

[Wouter In t Velt]

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.

[elm-discuss] Re: Edit Table Cell

[Wouter In t Velt]

Your Msg is the type you use to send data back. You actually send it to the 
Elm runtime. The Elm runtime then sends it to your update function, 
together with a model.

The nice thing is, you can pass more than one parameter in your message. If 
you define your message as:

type Msg = Input Int Int String

Your message has 2 integers (1 for column, 1 for row in a table) + a string.

You can then use that in your update function to update the correct column 
and row in your table.

Below is a simplified example, you can copy/paste to elm-lang.org/try

import Html exposing (..)
import Html.Attributes exposing (..)
import Html.Events exposing (onInput)

main =
  beginnerProgram { model = myTable, view = view, update = update }

myTable : List (List String)
myTable = 
  [ [ "Name", "Age", "Comment" ]
  , [ "Abe", "45", "" ]
  , [ "Bill", "69", "" ]
  , [ "Claire", "54", "" ]  
  ]

view model =
  div 
[]
[ table []
  (List.indexedMap viewRow model)
]

viewRow : Int -> List String -> Html Msg
viewRow rowIndex rowCells =
  tr [] 
 (List.indexedMap (viewCell rowIndex) rowCells)
 
viewCell : Int -> Int -> String -> Html Msg
viewCell rowIndex colIndex content =
  td
[ attribute "data-x" "1"
, attribute "data-y" "1"
, onInput (Input rowIndex colIndex)
, contenteditable True
, style [("border","solid black 1px")]
]
[ text content ]

type Msg = Input Int Int String


update msg model =
  case (Debug.log "msg:" msg) of
Input rowIndex colIndex str ->
  model
  |> updateList rowIndex (updateList colIndex (always str))
  
updateList : Int -> (a -> a) -> List a -> List a
updateList index func list =
  list
  |> List.indexedMap (\i item -> if i == index then func item else item)



-- 
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: Edit Table Cell

[Wouter In t Velt]

Op zondag 20 november 2016 20:17:04 UTC+1 schreef Thomas Shelton:
>
> I'm not sure onInput will work with TD's though.  I'm not seeing any 
> messages logged in the console.  
>

Yeah, you are right. `onInput` does not fire on TDs.
I have changed my example to include your custom `on` handler for the 
innerHTML (see below).

Here I also pass the extra info on row and column to your Msg and update. 
(and log).

There is another problem with contenteditable however:
If you run the example, you will see that everything you enter will be 
displayed in reverse. So "you"  will be displayed as "uoy".

This is because elm/ DOM does not change the cursor position if you change 
the content.
You may need some other tricks to ensure that the cursor will move as well.

I normally use simple (but styled)  fields for text editing in Elm.

Updated example:

import Html exposing (..)
import Html.Attributes exposing (..)
import Html.Events exposing (on)
import Json.Decode as JD exposing (Decoder)

main =
  beginnerProgram { model = model, view = view, update = update }

model =
  { table = myTable
  , log = ""
  }

myTable : List (List String)
myTable = 
  [ [ "Name", "Age", "Comment" ]
  , [ "Abe", "45", "" ]
  , [ "Bill", "69", "" ]
  , [ "Claire", "54", "" ]  
  ]

view model =
  div 
[]
[ table []
  (List.indexedMap viewRow model.table)
, div [] [ text <| "LOG = " ++ toString model.log ]
]

viewRow : Int -> List String -> Html Msg
viewRow rowIndex rowCells =
  tr [] 
 (List.indexedMap (viewCell rowIndex) rowCells)
 
viewCell : Int -> Int -> String -> Html Msg
viewCell rowIndex colIndex content =
  td
[ attribute "data-x" "1"
, attribute "data-y" "1"
, on "input" (JD.map (Input rowIndex colIndex) targetInnerHtml)
, contenteditable True
, style [("border","solid black 1px")]
]
[ text content ]

type Msg = Input Int Int String

targetInnerHtml : Decoder String
targetInnerHtml =
  JD.at ["target", "innerHTML"] JD.string


update msg model =
  case (Debug.log "msg:" msg) of
Input rowIndex colIndex str ->
  { model 
  | log = toString msg 
  , table = 
  model.table
  |> updateList rowIndex (updateList colIndex (always str))
  }
  
updateList : Int -> (a -> a) -> List a -> List a
updateList index func list =
  list
  |> List.indexedMap (\i item -> if i == index then func item else item)


-- 
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: Edit Table Cell

[Wouter In t Velt]

To get decent styling of tables I always use CSS flexbox, as classes for plane 
 and  tags.

I'm sure there are ways to  work too, but for me, they also tend to jump 
around and behave in unexpected ways.

For elm specifically, you could look at devoid/elm-mdl,
Or use material design light CSS classes in your elm elements.

-- 
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] why no more primes on 0.18 ?

[Wouter In t Velt]

The primes I currently use mostly in msg' and in model' in update functions.
It will take some getting used to, but not too bad I guess. I agree that 
newModel 
or similar is easier to read, so probably an improvement.

The backticks like in `andThen` I won't miss. It is probably more 
consistent anyway to use the piping pattern e.g. someMaybe |> Maybe.andThen 
someFunc

I am curious though, does anyone know what the 0.18 name for the current type' 
(with backtick) variable will be?
from html.Attributes, as used e.g. in input [ type' "text", value "my text 
input field" ] []

-- 
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] why no more primes on 0.18 ?

[Wouter In t Velt]

Never mind my question: type' will be type_

-- 
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: Proposal: rename foldl til foldLeft and foldr to foldRight

[Wouter In t Velt]

Op woensdag 26 oktober 2016 13:21:03 UTC+2 schreef Rupert Smith:
>
> Also worth pointing out that these libraries (and possibly others) have 
> adopted the convention of using a single 'l' or 'r' to mean from-the-left 
> and from-the-right: 
>

And the List library also has a scanl function (no scanr), which - should 
some renaming of foldl happen - would be nice to keep consistent.

-- 
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] tictactoe game with elm (newbie)

[Wouter In t Velt]

Op woensdag 26 oktober 2016 13:36:18 UTC+2 schreef Did:
>
> But It seems that, in the update function, currentBox always return 
> something because it doesn't update my model... I'm obviously doing 
> something wrong. But, for me, as all cells are unoccupied, this test should 
> return Nothing. What's wrong ?
>

The output of the currentBox function is not Nothing, but it is Just Nothing. 
A bit of a strange outcome.
If you remove the |> List.head from the currentBox function, you can see 
where things go wrong.

I'm sorry, but I don't know how to debug elm code in general, and in 
> particular with the elm lang try editor (I'm at work and I don't have elm 
> working on my machine...)
>

Below is a quick test I did in elm lang try editor. You can copy/paste this.
With elm, it is relatively easy to test parts of your code (because all 
functions are "pure", so the same input always gives the same output.)

import Html exposing (text)

type alias Box = { id : Int, player : Maybe Int }

filterRow: Int -> List Box -> Maybe Box
filterRow boxId row =
  row
  |> List.filter (\box -> box.id == boxId && not (box.player == Nothing))
  |> List.head

currentBox boxId = 
  List.map (filterRow boxId) cells
  |> List.head

cells = 
  [ [ Box 1 Nothing, Box 2 Nothing, Box 3 Nothing ]
  , [ Box 4 Nothing, Box 5 Nothing, Box 6 Nothing ]
  , [ Box 9 Nothing, Box 8 Nothing, Box 9 Nothing ]
  ]

main =
  text <| toString <| currentBox 5


-- 
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] why no more primes on 0.18 ?

[Wouter In t Velt]

Op woensdag 26 oktober 2016 13:51:03 UTC+2 schreef Andrew Radford:
>
> Yeah but it does beg the question whether
>
> type''
>
> should become type__
>

The type' variable was in the 0.17 Html.Attributes package. I don't think 
double primes are an issue there.

For other variables, that we define, I can see that double underscores 
would be less readable than double primes. But I guess the double 
[whatever] is probably a code smell, better served by a descriptive 
variants like oldModel, cleanedModel, newModel etcetera.

-- 
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: list of types is missing from docs page at http://elm-lang.org/docs

[Wouter In t Velt]

In the standard docs, there is some explanation of types here 
. But no exhaustive 
list.

In practice, I found that I did not need to learn any of the standard 
types. 
In contrast to any other language I know, Elm's compiler is really helpful 
in providing you with info about your types.
If you do not provide a type signature for you functions, the compiler will 
give you a suggestion, which in 90%+ cases you can simply copy to your 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.

[elm-discuss] Re: Another documentation item I think is needed

[Wouter In t Velt]

The comparison page you refer to is more a high-level comparison between 
javascript and elm syntax.
It does not look like it is intended to be in-depth.

I agree it would be useful to have some docs at some time summing up the 
pros and cons of List vs Array vs Set vs Dict.
But I am not sure that the "From javascript" place would be the right place.

PS: Getting an item from index in a List in Elm is quite straightforward

getFromList : Int -> List a -> Maybe a
getFromList index someList =
  List.head <| List.drop index someList

The main consideration vs Array or Dict (I think) is performance when the 
lists get larger.

Please note that this will return a Maybe type (same as Array, and Dict BTW)

-- 
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: Subscribe to a model value then call update function when condition is met

[Wouter In t Velt]

PS: The subscription to time is useful if you want some sort of timeout or 
delay between the user move and the AI move.
If you want to do the AI move immediately after the user move (without 
delay), 
a pattern with a recursive update call (and without subscription) is 
probably more suited.

Like so:

update msg model =
  case msg of
Toggle indexToToggle ->
  let
modelAfterUserMove =
  { model
  | board = move indexToToggle model.turn model.board
  }
  in
update AIMove modelAfterUserMove  -- here you do a recursive update 
call without any delay

AIMove ->
  ( fst (miniMax model 0)
  , Cmd.none
  )


-- 
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: Subscribe to a model value then call update function when condition is met

[Wouter In t Velt]

Op woensdag 12 oktober 2016 06:17:37 UTC+2 schreef hoang...@gmail.com:
>
> But if I do it this way, it's gonna return both the player's move and the 
> AI's move at the same time. What I want to have is that the game displays 
> the player's move THEN call minimax function on current model and THEN 
> display the AI's move
>

The recursive call still needs a separate Msg (AIMove) for the AIMove. This 
separate Msg is not needed: there is no outside event (user click or server 
or subscription) that calls this message. It is the update function itself 
(during processing of user moves) that calls this. So in that case, it 
would be better to use setup from Luke, to limit all Msg to outside events, 
and remove the AIMove message.

But it sounds like you want something else: you need 2 discrete model 
states (1 after player move, 1 after AI move), because you want *both model 
states to be displayed separately*.

And for that (as far as I know) you need the setup with subscription (+ 
some 'isProcessing' flag like OvermindDL1 suggested), and you also need to 
keep the AIMove message for the subscription command to call.

-- 
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: Another documentation item I think is needed

[Wouter In t Velt]

Op dinsdag 11 oktober 2016 23:36:49 UTC+2 schreef J. E. Marca:
>
> On first read I laughed out loud --- I don't know what <| does, and it 
> seems a random application of head and drop.  Reading closer, it *is* 
> straightforward as you say... drop first n items (one based count), then 
> get the next one (via List.head) and return that (which ends up being the 
> traditional zero based index count).  Clever, but not something I can come 
> up with on my own.  
>

Touché! my background is also in javascript (React + Flux). For me all the 
"|>" "<|" ">>" symbols where confusing at first as well. I guess I am 
already used to them :)
 

> Regardless, I wanted to *assign* to that element in the update loop, so 
> Array works better for me.  This is what I'm doing.  My view has a bunch of 
> buttons that onClick send a message and an index.  (The index value is 
> built into the html element via  Array.indexedMap).  
>

I pattern that I took with me from javascript as well is similar to your 
example:

   - Get one item from some collection (Array)
   - Apply a change function the item = make a new item
   - Put the new item back in the collection = make new collection with 
   updated item

But I ended up with a lot of "case someMaybe of" etcetera, and a lot of 
code lines.

What I do nowadays is different: pass an index + a change function to a 
collection, and get back the whole collection with the updated item in it.
Array.Extra 

 
has an Array.update function which allows you to do that.

Note however, that with Array.update, you do not know *if *an update has 
taken place, you just get the new Array back.
So the example below is slightly different from your original, because it 
will also call the getColorJson if the pvars did not change.
 
DetectorPlotVars ->
let
changePvars pvars = { pvars | on = not pvars.on }  -- 
local function that takes pvar and toggles "on" parameter

newArr = Array.update index changePVars model.detectorPlotVars

newModel = { model | detectorPlotVars = newArr }
in
( newModel
, getColorJson newModel 
)

-- 
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] Pattern matching on aliased types

[Wouter In t Velt]

Op dinsdag 11 oktober 2016 23:35:27 UTC+2 schreef Duane Johnson:
>
> toString is a bit magical in Elm, and can convert any type to a string.
>

Also note that if you apply toString to something that is already a String, 
it will add double quotes at the start and end.

-- 
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] http "middleware" options

[Wouter In t Velt]

Personally, I like the setup for as it is used in the time tracker SPA 
example (here) 
.

They have a separate file (Util.elm) with the following function:
cmdForRoute : Model -> List (Cmd Msg)

(This function is called inside the update function)
It generates a list of Cmd Msg.

inside cmdForRoute, various API functions are called.

The API is in a separate file, with specific functions for certain read or 
write calls, like: 
fetchProjects : Model -> (Http.Error -> Msg) -> (List Project -> Msg) -> Cmd 
Msg
fetchProjects model errorMsg msg =
get model "/projects" Decoders.projectsDecoder errorMsg msg

Each of those functions calls a more generic "get" or "put" function, which 
does the actual calls to server:
get : Model -> String -> JD.Decoder a -> (Http.Error -> Msg) -> (a -> Msg) 
-> Cmd Msg
get model path decoder errorMsg msg =
 ...


-- 
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: using js library inside elm?

[Wouter In t Velt]

>
> On Thu, Oct 13, 2016 at 5:46 AM, António Ramos  > wrote:
>
>> any example of calling an external js method ?
>>
>
Another example of calling external JS method is in the Todo.elm example app 
.
Where port to JS is used to store the model in LocalStorage. 

-- 
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: Subscribe to a model value then call update function when condition is met

[Wouter In t Velt]

(disclaimer: I am also quite new to Elm) 
I always try to avoid creating my own Cmd: there is usually a better, less 
bug-prone way to achieve this (e.g. with resursive update calls).

That said: I can see the logic in having a Msg originating from a "real" 
player, and another Msg from your AI player.

What you could do, is make a subscription to Time, that is only active if 
it is the AI's turn to move.
That way, you get a) a delay before the AI makes a move + b) you do not 
need to create your own command
Whenever it is the user's turn, or as soon as the game is over, the 
subscription is turned off.

Something like this:

subscriptions : Model -> Sub Msg
subscriptions model =
  if (gameIsNotFinished model && model.turn == AIToMove) then
Time.every second AIMove
  else
Sub.none

You would of course have to define your own functions to check if the game 
is still playing (no winner and no draw) and if it is the AI's turn to play.

-- 
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: How to insert an object into a list from a form

[Wouter In t Velt]

Op maandag 10 oktober 2016 14:58:56 UTC+2 schreef Ambrose Laing:
>
> I would modify the model to also contain a name, description and price, at 
> the top level.  These are uncommitted values.  By uncommitted I mean that 
> it should be possible to change any one of these without changing the 
> others, and yet your master list of all the items will not change because 
> you have not clicked the Run button yet.  This is because naturally it is 
> impossible to change all three items at once.  You change one, and you need 
> somewhere to hold the value you have changed while you modify the next one, 
> but before you commit a group of three of them as one article into your 
> master list.  
>

So your model would then look something like this:

type alias Model = 
  { articles : List Article
  , newName : String
  , newDescription : String
  , newPrice : String
  }


 
Your update would then include something like:

case msg of
  UpdateName inputString ->
{ model | newName = inputString }

  UpdatePrice inputString ->
 -- etcetera

Also, probably good to render these values in your view too:

[ input [ type' "text", placeholder "Enter a name...", onInput UpdateName, 
value model.newName ][]



It is only when you click Run that these three values are copied into an 
> Article and the article is appended to the List of articles in your model.
>

And the update for Run then becomes something like

case msg of
  Run ->
let
  newID = 
List.map (.id) model.articles -- get all IDs from the article list
|> List.maximum -- extract the maximum value (this is a Maybe type, 
because the list could be empty)
|> Maybe.withDefault 0 -- so give it a default value of 0
  newArticle = { id = newId, name = model.newName, ... (etcetera) }
in
  { model
  | articles = newArticle :: model.articles
  , newName = "" -- reset the input fields after adding
  , ... (etcetera)
  }

-- 
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: How to insert an object into a list from a form

[Wouter In t Velt]

Op dinsdag 11 oktober 2016 09:45:57 UTC+2 schreef Did:
>
> Thanks for your reply! Is there a better way to do this or this is a 
> common solution in elm?
>

Well, this is the best way I can think of :)

But seriously, as soon as your app grows, some functions in this setup may 
become big and bloated, with lots of unnecessarily repeated code. Then (and 
only then) you may want to separate out some functions to separate files.
That would very much depend on the direction in which your app will grow 
first, e.g.:

   - If your article gets 20 fields instead of , you could put all fields 
   in a Dict, and have a generic update function that takes a key, and updates 
   the field in the Dict.
   - If you get extensive validation on fields, you may have separate 
   validation on fields before updating model.
   - If your ID will be provided by a server, rather than your client, that 
   bit of code may change.
   - If IDs are generated in the client in lots of other places, you could 
   have a separate ID generator helper.
   - If you want to allow editing of an existing single line, you will need 
   to need a modify (instead of add) function
   - If you want to allow editing multiple lines at once, ..
   - Etcetera

-- 
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: Can I use css animations normally in elm?

[Wouter In t Velt]

Interesting! Having only discrete state in elm, with animations in CSS will 
definitely keep code simpler.

-- 
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: Elm post: feedback requested

[Wouter In t Velt]

Op dinsdag 29 november 2016 10:25:50 UTC+1 schreef John Orford:
>
> Just a note - sometimes a little repetition is helpful when learning or 
> teaching... At least that's what I tell myself when I find I am repeating 
> myself :)
>

Fully agree! Hope I made that clear by adding the workflow paragraph (first 
repeat, then clean) at the end.
Changed the subtitle anyway to remove the suggestion that any repetition is 
bad..

-- 
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 post: feedback requested

[Wouter In t Velt]

Thanks Max. I've taken out the somewhat repetitive paragraphs, to make the 
article itself also more compact and readable :)

As for using Dict, the exercise basically shows how to extract functions by 
rolling your own List equivalent of Dict.update.
Using Dict from the start would be less clear for the example. 
For collections where updating individual items is the dominant operations, 
I would agree that a Dict is more suitable.
I have added a note about List vs Dict at the end.

-- 
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: launchaco built in Elm

[Wouter In t Velt]

Op vrijdag 9 december 2016 06:55:07 UTC+1 schreef Marc Laventure:
>
> Hey! I am the author, great to hear your satisfaction with Launchaco. I am 
> also super excited to play around with elm on server side rendering! Fun 
> tidbit, we used golang to generate the html and assets when you click the 
> download button using the "html/template" library. Its very fun to use
>

Congrats Launchaco looks really nice and impressive!
Looks like a showcase you might want to plug on http://builtwithelm.co/

Also, in the community there is quite a bit of chatter about getting 
Editors built with Elm (with all kinds of challenges to work with 
contenteditable, read state from DOM elements etcetera). I am sure there's 
lots of people out there interested in your experiences in getting all this 
to work!

-- 
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] `Case of` branches grouping

[Wouter In t Velt]

Op vrijdag 9 december 2016 16:57:48 UTC+1 schreef Nick H:
>
> This only works if your type values aren't storing any data.
>

The equality test can be done if you are *not trying to pattern match* on 
the data in the type.
So

-- will work
if someValue == Just 42 then
  doStuffWith 42


is fine, but you cannot do:

-- this will not work
if someValue == Just a then
  doStuffWith a 

-- 
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: Design concepts. Too many Msg's?

[Wouter In t Velt]

Op dinsdag 13 december 2016 15:28:50 UTC+1 schreef Manu Rosa:
>
> ...I am curious as to what's the (communitie's) best practice to tackle 
> this.
>

Hi Manu,
One of the bigger examples (and my favorite) out there is the Time Tracker 
app: https://github.com/knewter/time-tracker
They use nested messages.
You may want to check that out.. 

-- 
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: onClick while shift key pressed

[Wouter In t Velt]

Here's how I would do it:

onShiftClick : msg -> Attribute msg
onShiftClick message =
let
hasShift shiftKey =
if shiftKey then
JD.succeed message
else
JD.fail "No shift key"
in
on "click" <|
JD.andThen hasShift <|
JD.at [ "shiftKey" ] JD.bool

More or less adapted from the TodoMVC app (which Json-fails on any other 
keycode than 13)

Working example on: https://runelm.io/c/6mf

-- 
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: Patterns for sum and product types

[Wouter In t Velt]

Op zondag 11 december 2016 20:01:09 UTC+1 schreef Brian Marick:
>
> Since FP has been around for a long time, too, I’m hoping that those 
> idioms and patterns have been written down, with a good effort toward 
> explaining them (with examples!) Where? 
>

As it happens, I just wrote a post on this topic over on Medium: 
https://medium.com/@wintvelt/how-to-make-impossible-states-impossible-c12a07e907b5

It is more of an experiment with different directions. It would be 
interesting if there were more extensive patterns around from people with 
more of an FP background..

-- 
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: Patterns for sum and product types

[Wouter In t Velt]

Great resources Rafal! Thanks for sharing!

-- 
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] How to use Dict.empty?

[Wouter In t Velt]

The error message from the compiler says that the third thing in your 
SomeRecordType should be a SomeOtherRecordType.

But you are passing it an empty Dict.

Which suggests that you have defined "SomeOtherRecordType" as something other 
than a Dict

-- 
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] Mutually dependent types

[Wouter In t Velt]

Op vrijdag 13 januari 2017 09:13:25 UTC+1 schreef Marco Perone:
>
> Coming back to my original question, supposing we have two mutually 
> recursive types, they must be in the same module and hence in the same 
> file, right?
>

Yes, that is what I would think too. 

I would argue that it would be nice to have the possibility to define 
> mutually recursive type in different files at least, if not in different 
> modules. What do you think?
>

I think this is impossible, because you would always get circular imports: 
each module needs import the type from the other module.

If you don't have mutually recursive types, (like one of your earlier 
responses suggest), but only reference with IDs, like:

type alias Team =
  { name : String
  , playerIDs : List String
  , id : String
  }

type alias Player = 
  { name : String
  , teamID : String
  , id : String
  }


Then you can put Team and Player in different modules.

-- 
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: Inter triplets communication.

[Wouter In t Velt]

This is a very educational discussion! Thank you for sharing links and 
examples.

As perhaps a minor point, I believe the elm-sortable-table does NOT belong 
in the list of "encapsulated state", "components", "triplets".
It does have a State type defined. But a notable difference with various 
other examples is that sortable-table does NOT have its own Msg or update 
function.

I've always seen the sortable-table as an example of how customizable and 
feature-rich you can get, *without *encapsulating an inaccessible local 
state.
React + flux lingo would be a *pure *component.

-- 
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: Why not components?

[Wouter In t Velt]

Op zondag 4 december 2016 15:02:02 UTC+1 schreef Rex van der Spuy:
>
> I found both Evan's sortable table example and your (excellent!) dropdown 
> menu just a few levels too advanced for my poor beginner's brain to fully 
> grok.
>

Glad you liked it! Were there any particular sections in the article that 
you found too advanced?
I'd be happy to make them more clear.
 

> For example, what would a simple, stand-alone, reusable, "pure" button 
> component look like that just triggers a message update in the parent 
> module when clicked?
>

A pure reusable button could look like this:
-- the pure button component
type alias Config msg =
  { clickMsg : msg
  , buttonText : String
  }

myButton : Config msg  -> Html msg
myButton config buttonText =
  button [ onClick config.clickMsg ] [ text config.ButtonText ]


-- usage in your main module
type Msg =
  ...
  | HandleButtonClick

buttonConfig : Button.Config Msg
buttonConfig =
  { clickMsg = HandleButtonClick
  , buttonText = "click me!"
  }

view : model -> Html Msg
view model =
  div []
[ p [] [ text "this is an example" ]
, Button.myButton buttonConfig
]

I'd put the message and the text both in a config, because I suspect these 
would be quite static, meaning the values would not change while running 
you app.

-- 
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] Why not components?

[Wouter In t Velt]

Hi All,
To explore and explain (in a beginner-friendly way) why making stateful 
reusable components in Elm is not always a good idea,

I have made a demo + write-up in 2 articles over on Medium.

Here are the links to the drafts:
https://medium.com/@wintvelt/a-reusable-dropdown-in-elm-part-1-d7ac2d106f13
https://medium.com/@wintvelt/a-reusable-dropdown-in-elm-part-2-9659ef988441

Any feedback would be welcome!

-- 
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] Why not components?

[Wouter In t Velt]

Op maandag 5 december 2016 16:58:34 UTC+1 schreef Peter Damoc:
>
> I just pushed the latest changes and the functionality should be 
> equivalent. 
> https://github.com/pdamoc/polymer-exploration
>

Looks great! I would suggest a small change in the country update: to only 
reset the city selector if the country selected is different from the 
previous selection.

CountryPicked country ->
{ model 
| country = Just country
, city = 
if model.country /= Nothing && model.country /= Just 
country then
Nothing
else
model.city
}


Would have liked to get some sort of onSelectedChanged event working, but 
even though the event is in the elm-polymer library, I had no luck getting 
it to work.
Also, would have loved to make a pull request for you repository on github, 
but I worry that my pull request would include the gazillion bower and npm 
installs as well.
Sorry, I'm a noob at github too.

-- 
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: One month with Elm, two questions

[Wouter In t Velt]

Op maandag 5 december 2016 21:00:35 UTC+1 schreef Frankie Sardo:
>
> Why does the update syntax accept just a new value instead of accepting a 
> function that updates (or creates) the new value?
>

Don't know about Clojure, but Elm likes you to be explicit and consistent 
about functions, meaning: if the function requires an argument, then you 
should provide an argument if you want to use the output of the function 
instead of the function itself.

So, you could use the functions you describe, as long as you also pass the 
argument:

  { model 
  | val1 = increase model.val1
  , val2 = always42 model.val2
  }

You can find a working example here 
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.