Re: [elm-discuss] Re: Stuck on custom event handlers and JSON decoder for select element

[Janis Voigtländer]

I think onInput will not give you the required event for select elements in
some browsers.
​

2016-07-08 16:45 GMT+02:00 Simon :

> With 0.17 I use onInput
>
> On Friday, 8 July 2016 14:47:01 UTC+2, Adam Waselnuk wrote:
>
> This is the last thing blocking me from a migration to 0.17. I can't seem
>> to wrap my head around capturing an on "change" event from a select
>> element. At this point my app is compiling, but when I toggle the select
>> dropdown, no messages are sent to the update function. If anyone can point
>> me to further reading on any of these topics I would very much appreciate
>> it.
>>
>> I have also created a Gist of the relevant (I think) code if anyone has a
>> minute to check that out:
>> https://gist.github.com/AWaselnuk/d0c9a01931c6e8e8a84d8743b6739df2
>>
> ​
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Splitting modules into several files

[Peter Damoc]

Of course one can sometime get into a circular dependency using this
pattern of code structuring. (e.g. if one has two functions in different
areas that might need each other.)

Elm is pragmatic. If *a good case* for splitting the code in multiple files
can be made, it might implement that.



On Fri, Jul 8, 2016 at 6:27 PM, Robert Walter 
wrote:

> Hi Peter,
>
> thank you again, this is a great reference.
> Would you agree that, while your solution is pretty flexible, it is not
> equivalent to a feature which would allow one to spread out a module to
> several files. Don't get me wrong, I really like your example and how it
> illustrates the capabilities of aliases and imports to unify several
> modules under a common interface, but due to the imports, it is a bit more
> restricted and wouldn't allow one to have "function a" in ModuleName.A and
> "function b" in ModuleName.B and call those function from the other module.
>
> I don't have a particular use case where something like this is required
> and I think the option you highlighted covers most use cases where you want
> to separate a large module into several smaller ones, so thanks again!
> Robert
>
> On Friday, July 8, 2016 at 2:31:09 PM UTC+2, Peter Damoc wrote:
>>
>> I've created some sample code starting from the Counter Example
>>
>> https://github.com/pdamoc/elm-assistance/tree/master/MultiFile
>>
>> Please take a look.
>>
>>
>>
>>
>> On Fri, Jul 8, 2016 at 2:14 PM, Robert Walter 
>> wrote:
>>
>>> Thanks Peter for showing these options.
>>> In both cases, however, the modules themselves wouldn't be able to share
>>> types, for example. I could think of a "physical" separation of a module's
>>> code like so:
>>>
>>> src
>>> |_ moduleName.model.elm
>>> |_ moduleName.view.elm
>>> |_ moduleName.update.elm
>>>
>>> Where I define type aliases and types in "moduleName.model.elm" and
>>> where I can access those in the other files (given that they all are part
>>> of the same module). Maybe I'm missing something?
>>>
>>>
>>> On Friday, July 8, 2016 at 11:03:23 AM UTC+2, Peter Damoc wrote:

 If you want you can break a module into multiple files and offer a
 unified interface.

 I can think of two ways to do this.

 1. with folders, where you push all the module files into its own
 folder and add that folder to the "source-directories" in elm-package.json.
 2. with prefixing/suffixing in file names / module names.

 In both cases the pattern is the same, you create aliases:

 module ModuleName exposing (first, second, third)

 import ModuleName.First
 import ModuleName.Second
 import ModuleName.Third

 first = ModuleName.First.first

 second = ModuleName.Second.second

 third = ModuleName.Third.third


 If it helps, you can think about the actual ModuleName as playing the
 role of __init__.py in a python module. ;)



 On Fri, Jul 8, 2016 at 11:48 AM, Robert Walter 
 wrote:

> Hello,
>
> as far as I can tell, it is a requirement that a module names matches
> its file name, which means that one cannot split a module into several
> files, correct?
> I'm curious about the rational behind it? Is it "just" so that the
> compiler has an easier time resolving imports or are there other reasons 
> as
> well?
>
> One could argue that it forces users to keep things that belong
> together logically also physically together and that it encourages you to
> keep modules small. On the other hand, message communication between
> modules seems to be a bit unwieldy which makes me hesitant to create too
> big of a module hierarchy. From a beginner's point of view, I like the 
> idea
> of "partial module" declarations, but I can imagine that there are good
> reasons against that.
>
> best,
> Robert
>
> --
> You received this message because you are subscribed to the Google
> Groups "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to elm-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



 --
 There is NO FATE, we are the creators.
 blog: http://damoc.ro/

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elm-discuss...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 

Re: [elm-discuss] Debouncing in Elm 0.17

[Peter Damoc]

Here is another way to structure the code with the part that is related to
debouncing extracted into its own module:
https://github.com/pdamoc/elm-assistance/tree/master/Debounce

As for debouncing at the language level, I think we might have the wiring
for that already in Effect Managers.




On Fri, Jul 8, 2016 at 5:02 PM, Charlie Koster  wrote:

> Thanks for the replies. The custom Time Tick code is more understandable
> and straightforward in my opinion so I'll use that in the future.
>
> I'm curious if there's an opportunity to build debouncing into the
> language. That seems possible for subscriptions but I'm not so sure about
> other actions that the update function receives.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Splitting modules into several files

[Robert Walter]

Hi Peter,

thank you again, this is a great reference.
Would you agree that, while your solution is pretty flexible, it is not 
equivalent to a feature which would allow one to spread out a module to 
several files. Don't get me wrong, I really like your example and how it 
illustrates the capabilities of aliases and imports to unify several 
modules under a common interface, but due to the imports, it is a bit more 
restricted and wouldn't allow one to have "function a" in ModuleName.A and 
"function b" in ModuleName.B and call those function from the other module.

I don't have a particular use case where something like this is required 
and I think the option you highlighted covers most use cases where you want 
to separate a large module into several smaller ones, so thanks again!
Robert

On Friday, July 8, 2016 at 2:31:09 PM UTC+2, Peter Damoc wrote:
>
> I've created some sample code starting from the Counter Example 
>
> https://github.com/pdamoc/elm-assistance/tree/master/MultiFile
>
> Please take a look. 
>
>
>
>
> On Fri, Jul 8, 2016 at 2:14 PM, Robert Walter  > wrote:
>
>> Thanks Peter for showing these options.
>> In both cases, however, the modules themselves wouldn't be able to share 
>> types, for example. I could think of a "physical" separation of a module's 
>> code like so:
>>
>> src
>> |_ moduleName.model.elm
>> |_ moduleName.view.elm
>> |_ moduleName.update.elm
>>
>> Where I define type aliases and types in "moduleName.model.elm" and where 
>> I can access those in the other files (given that they all are part of the 
>> same module). Maybe I'm missing something?
>>
>>
>> On Friday, July 8, 2016 at 11:03:23 AM UTC+2, Peter Damoc wrote:
>>>
>>> If you want you can break a module into multiple files and offer a 
>>> unified interface. 
>>>
>>> I can think of two ways to do this. 
>>>
>>> 1. with folders, where you push all the module files into its own folder 
>>> and add that folder to the "source-directories" in elm-package.json. 
>>> 2. with prefixing/suffixing in file names / module names. 
>>>
>>> In both cases the pattern is the same, you create aliases: 
>>>
>>> module ModuleName exposing (first, second, third)  
>>>
>>> import ModuleName.First 
>>> import ModuleName.Second
>>> import ModuleName.Third 
>>>
>>> first = ModuleName.First.first 
>>>
>>> second = ModuleName.Second.second
>>>
>>> third = ModuleName.Third.third
>>>
>>>
>>> If it helps, you can think about the actual ModuleName as playing the 
>>> role of __init__.py in a python module. ;) 
>>>
>>>  
>>>
>>> On Fri, Jul 8, 2016 at 11:48 AM, Robert Walter  
>>> wrote:
>>>
 Hello,

 as far as I can tell, it is a requirement that a module names matches 
 its file name, which means that one cannot split a module into several 
 files, correct?
 I'm curious about the rational behind it? Is it "just" so that the 
 compiler has an easier time resolving imports or are there other reasons 
 as 
 well?

 One could argue that it forces users to keep things that belong 
 together logically also physically together and that it encourages you to 
 keep modules small. On the other hand, message communication between 
 modules seems to be a bit unwieldy which makes me hesitant to create too 
 big of a module hierarchy. From a beginner's point of view, I like the 
 idea 
 of "partial module" declarations, but I can imagine that there are good 
 reasons against that.

 best,
 Robert

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Elm Discuss" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to elm-discuss...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> -- 
>>> There is NO FATE, we are the creators.
>>> blog: http://damoc.ro/
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Configuring embedded Ace Editor via port

[Robert Walter]

I found a way to achieve what I want:

In the view function that adds the Ace editor, I send a message once it is 
ready (I assume in this use case it is fine to use Json.succeed, no?):

type Msg = EditorReady

renderScript : Script -> Html Msg
renderScript script =
node "juicy-ace-editor"
[ id "editor-container", on "editor-ready" (Json.succeed EditorReady
) ]
[ ... ]

In my update function, I trigger the port once the message arrives:

port configureAce : String -> Cmd m

update : Msg -> AppState -> ( AppState, Cmd Msg )
update msg appState =
case msg of
SelectView i ->
( { appState | viewSelected = i }, Cmd.none )

EditorReady -> 
( appState, configureAce "ace/theme/monokai")

best,
Robert


On Thursday, July 7, 2016 at 5:04:55 PM UTC+2, Robert Walter wrote:
>
> Hello,
>
> first of all: if someone knows of another, better way of achieving what 
> I'm trying to do, I'd be happy to hear about it.
>
> In my Elm app, I embed an Ace editor using juicy-ace 
> . In order to configure the 
> editor instance (e.g. setting a certain theme) I think I need to use a port 
> to call some JavaScript.
> However, my editor is not always in the dom. In other words, it is 
> conditionally rendered based on the selected tab of my app. Here's a 
> screenshot to illustrate that.
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> My current "solution" doesn't quite work, because I "trigger" the port 
> when the user clicks on the "Dialog" tab. This action updates my model to 
> render the dialog tab next,
> but the port is triggered before the view is rendered, so that I cannot 
> apply any theme or other configuration.
> When I click the dialog tab a second time, the configuration is applied 
> just fine (hence, I know the JavaScript side works),
>
> Here are some code snippets that show the relevant parts.
>
> index.html -- where I want to configre the Ace Editor.
>   
> var app = Elm.App.fullscreen();
>
> // configureAce is the port in Elm
> app.ports.configureAce.subscribe(function(theme) {
>   var aceContainer = document.getElementById("editor-container");
>
>   console.log("Called!");
>
>   if(aceContainer != null)
> aceContainer.editor.setTheme(theme);
> });
>   
>
> App.elm -- my main *.elm file, where I "trigger" the port 
> port configureAce : String -> Cmd a
>
> update : Msg -> AppState -> ( AppState, Cmd Msg )
> update msg appState =
> case msg of
> SelectView i ->
> let
>   cmd = 
> if ((indexToView i) == Dialog)
> then configureAce "ace/theme/monokai"
> else Cmd.none 
> in
> ( { appState | viewSelected = i }, cmd)
> ...
>
> One thing I tried but failed with the same behavior as above was the 
> following: Instead of directly triggering the port when the Dialog tab is 
> selected, I wanted to create a Cmd that will be run by elm and only once it 
> is fed back in the update function, I trigger the port, like so:
>
> port configureAce : String -> Cmd a
>
> update : Msg -> AppState -> ( AppState, Cmd Msg )
> update msg appState =
> case msg of
> SelectView i ->
> let
>   cmd = 
> if ((indexToView i) == Dialog)
> then (toCmd ConfigureAce) --configureAce 
> "ace/theme/monokai"
> else Cmd.none 
> in
> ( { appState | viewSelected = i }, cmd )
> 
> ConfigureAce -> 
>   (appState, configureAce "ace/theme/monokai")
>
>
> toCmd : msg -> Cmd msg
> toCmd msg =
>   Task.perform (always msg) (always msg) (Task.succeed msg)
>
> 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: Stuck on custom event handlers and JSON decoder for select element

[Simon]

With 0.17 I use onInput

On Friday, 8 July 2016 14:47:01 UTC+2, Adam Waselnuk wrote:

This is the last thing blocking me from a migration to 0.17. I can't seem 
> to wrap my head around capturing an on "change" event from a select 
> element. At this point my app is compiling, but when I toggle the select 
> dropdown, no messages are sent to the update function. If anyone can point 
> me to further reading on any of these topics I would very much appreciate 
> it. 
>
> I have also created a Gist of the relevant (I think) code if anyone has a 
> minute to check that out: 
> https://gist.github.com/AWaselnuk/d0c9a01931c6e8e8a84d8743b6739df2
>
​

-- 
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] Debouncing in Elm 0.17

[Peter Damoc]

This is how I implemented it in the elmChallenges
https://github.com/pdamoc/elmChallenges/blob/master/challenge4.elm#L76-L82



On Fri, Jul 8, 2016 at 4:19 PM, Charlie Koster  wrote:

> Now that signals are gone I'm not quite sure how I would debounce inputs.
> The typical example is an auto-complete search box or a typeahead.
>
> In Elm 0.17, what is the recommended way for debouncing inputs/actions
> received in the update function? If on every keypress on an input box my
> update function is called and it returns a task to perform a new search
> based on that input, I wouldn't want to make http requests on every
> keypress. I'd want to debounce those requests.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Debouncing in Elm 0.17

[Frederick Yankowski]

There is a published package that helps with de-bouncing: 
http://package.elm-lang.org/packages/athanclark/elm-debouncer/2.0.0/

I have also done it like this: 
https://github.com/fredcy/example-elm-debounce/blob/master/Debounce.elm

On Friday, July 8, 2016 at 8:19:40 AM UTC-5, Charlie Koster wrote:

Now that signals are gone I'm not quite sure how I would debounce inputs. 
> The typical example is an auto-complete search box or a typeahead.
>
> In Elm 0.17, what is the recommended way for debouncing inputs/actions 
> received in the update function? If on every keypress on an input box my 
> update function is called and it returns a task to perform a new search 
> based on that input, I wouldn't want to make http requests on every 
> keypress. I'd want to debounce those requests.
>
​

-- 
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] Debouncing in Elm 0.17

[Charlie Koster]

Now that signals are gone I'm not quite sure how I would debounce inputs. 
The typical example is an auto-complete search box or a typeahead.

In Elm 0.17, what is the recommended way for debouncing inputs/actions 
received in the update function? If on every keypress on an input box my 
update function is called and it returns a task to perform a new search 
based on that input, I wouldn't want to make http requests on every 
keypress. I'd want to debounce those requests.

-- 
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: Draft blog post - "How to Use Elm at Work" - looking for feedback

[Adam Waselnuk]

I would suggest the following change:

Embedding Elm in some big JavaScript project is not very hard. It's like 
> three lines of JS, but it feels like no one knows about them! So I created 
> react-elm-components to make it much more obvious.


change to something like:

Elm is optimized for embedding into your existing JavaScript projects. With 
> about three lines of JS, you can have Elm components interoperating with 
> your app giving you the opportunity to experiment and experience the power 
> of Elm sooner! I have created react-elm-components to make this even 
> simpler.


Still needs work probably but basically consider the following: "some big 
project" is vague and sounds a bit dismissive of existing JS projects. "not 
very hard" is probably true but try not to assume what is hard for other 
people. "It's like three lines .." also sounds dismissive and like anyone 
should know this obvious thing. It's very obvious to us but not to the 
people you want to capture in this post. Finally, try front loading a bit 
of the Elm awesomeness! Why do I care to embed an Elm component? Probably 
because I want to experiment and Elm is just really great!

-- 
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] Stuck on custom event handlers and JSON decoder for select element

[Adam Waselnuk]

This is the last thing blocking me from a migration to 0.17. I can't seem 
to wrap my head around capturing an on "change" event from a select 
element. At this point my app is compiling, but when I toggle the select 
dropdown, no messages are sent to the update function. If anyone can point 
me to further reading on any of these topics I would very much appreciate 
it. 

I have also created a Gist of the relevant (I think) code if anyone has a 
minute to check that 
out: https://gist.github.com/AWaselnuk/d0c9a01931c6e8e8a84d8743b6739df2

-- 
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] Port compiler error message

[Devendra Gera]

I had run into the same thing a while ago. The error message is not
helpful at all, but I fixed it (with help from the elm Slack channel)
by changing the port signature from

  port portName : X -> Cmd Msg

to

  port portName : X -> Cmd msg

(note the lowercase `msg`, which makes it generic).

Cheers,
--gera.

-- 
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: Draft blog post - "How to Use Elm at Work" - looking for feedback

[José Lorenzo Rodríguez]

This is great news!!

Do you know if this will work when using server side rendering? If not, how 
big of an effort would it be to support it?

On Thursday, July 7, 2016 at 1:46:27 AM UTC+2, Evan wrote:
>
> *DRAFT - Do not share the npm package or draft blog post yet!*
>
> Embedding Elm in some big JavaScript project is not very hard, but I think 
> you currently need quite a lot of experience with Elm for this to be 
> obvious. It's like three lines of JS, but you typically learn those lines 
> pretty late.
>
> So I created react-elm-components 
>  to make it much more 
> obvious.
>
> In addition, I drafted a blog post called How to Use Elm at Work 
>  that 
> outlines the typical success story I hear from people that introduced Elm 
> successfully. Let me know what you think!
>
> I am planning to announce both of these things on Monday, so *please do 
> not share react-elm-components or the blog post before then*! It is cool 
> to talk about it in Elm community forums of course, but please not on 
> Twitter, Reddit, HN, etc!
>
>
> Context
>
> I released keyed HTML nodes 
>  last week. 
> This was the final technical hurdle blocking a blog post about the 
> performance improvements in elm-lang/html. It is much faster than a lot of 
> things! As I drafted *that* blog post, I realized it would be helpful to 
> publish "How to Use Elm at Work" first. I hope that "Elm is faster than X" 
> will get a decent group of people interested in giving it a shot, so I want 
> to make the next steps as clear as possible!
>

-- 
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: element.clientWidth, element.clientHeight, ...

[Petr Bolf]

OK, here is any good answer 
https://medium.com/@debois/elm-the-dom-8c9883190d20#.58f1dq69j

Dne pátek 8. července 2016 0:37:24 UTC+2 Petr Bolf napsal(a):
>
> Hi,
> I use elm with elm-html package (virtual dom)
> Why I can read elements properties element.clientWidth, 
> element.clientHeight etc.
>
> 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: Draft blog post - "How to Use Elm at Work" - looking for feedback

[Rohan Orton]

>>> Richard has the best *strats*.

Is this a typo? Or is Richard a collector of guitars?

On Thursday, 7 July 2016 00:46:27 UTC+1, Evan wrote:
>
> *DRAFT - Do not share the npm package or draft blog post yet!*
>
> Embedding Elm in some big JavaScript project is not very hard, but I think 
> you currently need quite a lot of experience with Elm for this to be 
> obvious. It's like three lines of JS, but you typically learn those lines 
> pretty late.
>
> So I created react-elm-components 
>  to make it much more 
> obvious.
>
> In addition, I drafted a blog post called How to Use Elm at Work 
>  that 
> outlines the typical success story I hear from people that introduced Elm 
> successfully. Let me know what you think!
>
> I am planning to announce both of these things on Monday, so *please do 
> not share react-elm-components or the blog post before then*! It is cool 
> to talk about it in Elm community forums of course, but please not on 
> Twitter, Reddit, HN, etc!
>
>
> Context
>
> I released keyed HTML nodes 
>  last week. 
> This was the final technical hurdle blocking a blog post about the 
> performance improvements in elm-lang/html. It is much faster than a lot of 
> things! As I drafted *that* blog post, I realized it would be helpful to 
> publish "How to Use Elm at Work" first. I hope that "Elm is faster than X" 
> will get a decent group of people interested in giving it a shot, so I want 
> to make the next steps as clear as possible!
>

-- 
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] Splitting modules into several files

[Robert Walter]

Hello,

as far as I can tell, it is a requirement that a module names matches its 
file name, which means that one cannot split a module into several files, 
correct?
I'm curious about the rational behind it? Is it "just" so that the compiler 
has an easier time resolving imports or are there other reasons as well?

One could argue that it forces users to keep things that belong together 
logically also physically together and that it encourages you to keep 
modules small. On the other hand, message communication between modules 
seems to be a bit unwieldy which makes me hesitant to create too big of a 
module hierarchy. From a beginner's point of view, I like the idea of 
"partial module" declarations, but I can imagine that there are good 
reasons against that.

best,
Robert

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