Re: [elm-discuss] Abort tasks?

[Evan Czaplicki]

Process.spawn and Process.kill let you "kill tasks". Killing a process that
has an HTTP request pending will cancel the request as well.

Interprocess communication is not ready yet, but the current API can cover
some use cases.

On Tuesday, June 28, 2016, Mark Hamburg  wrote:

> I would absolutely tag the tasks. You can do this in the response action.
> I recommend keeping a counter in the model and advancing it whenever the
> basis for requests changes.
>
> Aborting would be ideal but it's harder or potentially impossible at
> present.
>
> Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Sent from Gmail Mobile

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

[Mark Hamburg]

On Jun 28, 2016, at 6:12 AM, Wouter In t Velt  wrote:
> 
> 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.

This is a place where presentation (view) hierarchy and data (model) hierarchy 
mix uncomfortably. Removal from the list of children has little to do with the 
child unless there are other updates that accompany the removal that only the 
child understands. It is purely an update to the parent. This is different from 
the child needing a way to express "I've run out of money". That is based on an 
update to information local to the child. What muddles this up is that the 
remove button is often presented as part of the presentation of the child and, 
in The Elm Architecture, we are trained to think of the presentation as being 
built by a view function from model to HTML and hence if the presentation 
contains a removal button then remove must be a message destined for the model.

The Elm 0.16 architecture tutorial handled this by providing a separate address 
to which the remove message could be delivered.

The Elm 0.17 documentation at present is silent on the subject. There have been 
proposals for how to deal with this in an Elm 0.16 style but they haven't been 
officially endorsed and result in view functions with a return type of Html 
parentMsg as opposed to Html ChildMsg which is a little ugly. There are also 
suggestions to use extra return values from the update function (as the essays 
linked to in this thread do) but those result in the child update function 
containing entries that basically just serve to route the remove message up to 
the parent thereby contaminating the update function with a complexity that 
previously only affected the view function.

I've still been on Elm 0.16 because I've been waiting for key support, but I've 
been looking at 0.17 and one thing that does have me worried is that in getting 
rid of addresses may have increased coupling between the view hierarchy — 
driven by UX design concerns — and the model hierarchy which should be driven 
by data consistency concerns. While the default handling in the past for 
addresses led to a tight correspondence between the hierarchies, one could 
always work around it by providing an address along with a model (or as part of 
a model) wherever appropriate and it didn't feel too unnatural. One could 
probably do something similar by using routing functions(*) in much the same 
way as addresses in 0.16 but they feel like a fight against the intended use 
pattern.

But all of those judgments are suspended pending more complete documentation 
for these cases for 0.17.

Mark

(*) view : (msg -> rootMsg) -> model -> Html rootMsg

This could just use the standard Elm 0.17 routing instead (or in its 
implementation) but it stresses that the route isn't driven by the presentation 
but is rather information describing how to get messages to the relevant 
portion of the model.

To make it work well with lazy HTML, it really needs to be based on embedding 
the route into the model and only computing it at initialization time for that 
piece of the 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: elm data visuslization/chating

[Max Goldstein]

In my opinion, d3 is one of the very parts of JavaScript that doesn't suck, 
so I don't mind using it. D3 takes advantage of a lot of quirky JS 
features, like functions and arrays as objects, variable argument counts, 
and prototypal inheritance. It would be tricky to port everything over to 
Elm, perhaps excepting stateless functions like scales.

That said, there needs to be a way to "cordon off" a DOM subtree from 
diffing so you can do your d3 stuff in it. I know you can do this in React 
by setting "shouldComponentUpdate" to always return false.

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

[Jacob Oakes]

I just wanted to share a project that I have been working on called elm 
news. It allows you to see everything happening in the elm community from 
elm-discuss, elm-dev, reddit, and hacker news all in one place. If you are 
interested you can find it at https://oakesja.github.io/elm-news/

-- 
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: Try out the 0.17.1 beta

[Will Clardy]

Richard,

Works like a charm for me on Arch Linux. Thanks for the update!

On Tuesday, June 28, 2016 at 5:26:26 PM UTC-4, Richard Feldman wrote:
>
> Hi Stuart (and others!)
>
> You can now get this via:
>
>
> npm install -g elm@0.17.1-alpha
>
>
> I'd appreciate it if folks could try out the npm install route and let me 
> know whether it worked or not...especially on Windows or Linux!
>
>>

-- 
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: Try out the 0.17.1 beta

[Richard Feldman]

Hi Stuart (and others!)

You can now get this via:


npm install -g elm@0.17.1-alpha


I'd appreciate it if folks could try out the npm install route and let me 
know whether it worked or not...especially on Windows or Linux!

>

-- 
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] Has elm reactor 0.17 dropped support for HTML files?

[Stuart Axon]

Is there an elm package command to upgrade to the beta ?

On Tuesday, June 28, 2016 at 8:23:49 PM UTC+1, Evan wrote:
>
> Try the 0.17.1 beta
>
> On Tuesday, June 28, 2016, Stuart Axon  
> wrote:
>
>> Hi,
>>I just started with elm and this is a bit confusing.   - I guess I 
>> need a separate http server for now to see the output ?
>>
>> So workflow - is:
>>
>> Compile, then refresh browser that is pointing at separate http server?
>>
>> S
>>
>>
>>
>> On Sunday, May 15, 2016 at 9:57:26 PM UTC+1, John Orford wrote:
>>>
>>> Yeh the manual compiles are irksome
>>>
>>> Paul D  schrieb am So., 15. Mai 2016 17:07:
>>>
 It's not just serving the files, it's also debugging. It'd be pretty 
 sad if embedding Elm meant that you couldn't use its main (sole?) 
 development tool. I'm glad to hear that HTML support is coming back!


 On Sunday, May 15, 2016 at 3:16:07 AM UTC-6, John Watson wrote:
>
> Don't worry - I'm quite happy just serving it with Apache.
>
> On Sunday, 15 May 2016 01:29:06 UTC+1, Evan wrote:
>>
>> It's probably a mistake in how I added the "pretty" view. Like I've 
>> been saying to everyone about reactor, I needed to release without 
>> *everything* or I'd never get 0.17 out the door. Things will be 
>> fixed up later!
>>
>> On Sat, May 14, 2016 at 8:11 AM, John Watson  
>> wrote:
>>
>>> elm-reactor --version gives 0.17.0.  I'm running 64-bit Ubuntu.
>>>
>>> On Saturday, 14 May 2016 16:07:29 UTC+1, Joey Eremondi wrote:

 Can you verify what version of Elm reactor is being used? 
 On May 14, 2016 2:43 AM, "John Watson"  wrote:

> I'm affected by this, too.  If I compile with --output Main.html 
> then an Html file is produced with the new syntax of 
> Elm.Main.fullscreen(); 
> however elm reactor no longer serves it.  I need this to test HTTP 
> requests 
> which otherwise will give me CORS errors.  Am I missing something 
> obvious?
>
> On Friday, 13 May 2016 09:51:39 UTC+1, Paul D wrote:
>>
>> I'm using the fullscreen function to embed an Elm app in an HTML 
>> file. With Elm 0.16, I could run elm-reactor and then go to 
>> http://localhost:8080/myfile.html to use the app. After 
>> upgrading to Elm 0.17, elm-reactor no longer serves the HTML. 
>> Instead it 
>> just displays the file contents, much like view source would. Is 
>> this a bug 
>> or was that functionality deliberately removed?
>>
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, 
> send an email to elm-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
 -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, 
>>> send an email to elm-discuss...@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...@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.
>>
>
>
> -- 
> Sent from Gmail Mobile
>

-- 
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] Try out the 0.17.1 beta

[Douglas Correa]

Evan, thanks for the new version,

And I really like this part of README.md (
https://github.com/elm-lang/elm-reactor/blob/master/README.md#note-about-time-travel
)

Time travel is very useful in "Redux world" and it would be in Elm too.

Douglas

On Tue, Jun 28, 2016 at 3:30 PM, Evan Czaplicki  wrote:

> The 0.17 release revealed a few rough spots. Particularly for new folks
> who were trying to install evancz/elm-html instead of elm-lang/html. So I
> did a bunch of bug fixes for stuff along these lines. The main changes are:
>
>- Default dependencies in elm-package.json are core *and*
> elm-lang/html.
>- Error messages for elm-package are improved (e.g. this
>
> and this
>
>)
>- Packages download concurrently (a.k.a. faster)
>- Make elm-reactor serve assets better. Was messing up CSS and HTML.
>- Use ~/.elm/0.17.1/ so all globally cached things are isolated
>- Binaries are much smaller (~120MB to ~40MB on OSX)
>
> I have some beta binaries ready. Please give them a try:
>
>- mac 
>- windows 
>
> It is just a better version of 0.17, so you should be able to install and
> just have things be nicer. If you try it and want to go back to 0.17, just
> run the installers here . The most recent
> one takes precedence.
>
> I'm hoping to do a relatively quite announcement on twitter tomorrow, so
> let me know if you run into any problems!
>
> --
> 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] Has elm reactor 0.17 dropped support for HTML files?

[Evan Czaplicki]

Try the 0.17.1 beta

On Tuesday, June 28, 2016, Stuart Axon  wrote:

> Hi,
>I just started with elm and this is a bit confusing.   - I guess I need
> a separate http server for now to see the output ?
>
> So workflow - is:
>
> Compile, then refresh browser that is pointing at separate http server?
>
> S
>
>
>
> On Sunday, May 15, 2016 at 9:57:26 PM UTC+1, John Orford wrote:
>>
>> Yeh the manual compiles are irksome
>>
>> Paul D  schrieb am So., 15. Mai 2016 17:07:
>>
>>> It's not just serving the files, it's also debugging. It'd be pretty sad
>>> if embedding Elm meant that you couldn't use its main (sole?) development
>>> tool. I'm glad to hear that HTML support is coming back!
>>>
>>>
>>> On Sunday, May 15, 2016 at 3:16:07 AM UTC-6, John Watson wrote:

 Don't worry - I'm quite happy just serving it with Apache.

 On Sunday, 15 May 2016 01:29:06 UTC+1, Evan wrote:
>
> It's probably a mistake in how I added the "pretty" view. Like I've
> been saying to everyone about reactor, I needed to release without
> *everything* or I'd never get 0.17 out the door. Things will be fixed
> up later!
>
> On Sat, May 14, 2016 at 8:11 AM, John Watson 
> wrote:
>
>> elm-reactor --version gives 0.17.0.  I'm running 64-bit Ubuntu.
>>
>> On Saturday, 14 May 2016 16:07:29 UTC+1, Joey Eremondi wrote:
>>>
>>> Can you verify what version of Elm reactor is being used?
>>> On May 14, 2016 2:43 AM, "John Watson"  wrote:
>>>
 I'm affected by this, too.  If I compile with --output Main.html
 then an Html file is produced with the new syntax of 
 Elm.Main.fullscreen();
 however elm reactor no longer serves it.  I need this to test HTTP 
 requests
 which otherwise will give me CORS errors.  Am I missing something 
 obvious?

 On Friday, 13 May 2016 09:51:39 UTC+1, Paul D wrote:
>
> I'm using the fullscreen function to embed an Elm app in an HTML
> file. With Elm 0.16, I could run elm-reactor and then go to
> http://localhost:8080/myfile.html to use the app. After upgrading
> to Elm 0.17, elm-reactor no longer serves the HTML. Instead it just
> displays the file contents, much like view source would. Is this a 
> bug or
> was that functionality deliberately removed?
>
 --
 You received this message because you are subscribed to the Google
 Groups "Elm Discuss" group.
 To unsubscribe from this group and stop receiving emails from it,
 send an email to elm-discuss...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to elm-discuss...@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...@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.
>


-- 
Sent from Gmail Mobile

-- 
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 data visuslization/chating

[Nicolas Lawler]

I looked into elm-d3 since the app I'm building will eventually have a 
visualization component. What I found was that the logical conclusion of 
porting d3 to elm was a system that smells a lot like the good old elm 
architecture! See here 
 for a 
discussion of this by the author of elm-d3. Taken literally, you can make a 
couple outrageous inferences from this:

1. d3 is good for visualization in javascript insofar as it brings 
"elm-like" reactivity to the table.
2. Vanilla elm and the elm architecture are sufficient for "d3-like" 
visualization, right now.

My hunch is that vanilla elm is not sufficient by itself, but it only needs 
1 or 2 libraries that provide view-level abstractions for common use cases 
to be sufficient. As far as I know these libraries don't exist yet, but boy 
would it be cool if they did. Elm could capture a whole audience of people 
who are only putting up with js because of d3.

Sorry for hijacking your thread with my personal ranting/library wishlist, 
but I want see if my view of things is accurate and at least motivate more 
work in this direction. 

If you're looking to get something done right now, I'd say your best bet is 
to port out to d3 or another javascript visualization library.  

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

[elm-discuss] Try out the 0.17.1 beta

[Evan Czaplicki]

The 0.17 release revealed a few rough spots. Particularly for new folks who
were trying to install evancz/elm-html instead of elm-lang/html. So I did a
bunch of bug fixes for stuff along these lines. The main changes are:

   - Default dependencies in elm-package.json are core *and* elm-lang/html.
   - Error messages for elm-package are improved (e.g. this
   
and this
   
   )
   - Packages download concurrently (a.k.a. faster)
   - Make elm-reactor serve assets better. Was messing up CSS and HTML.
   - Use ~/.elm/0.17.1/ so all globally cached things are isolated
   - Binaries are much smaller (~120MB to ~40MB on OSX)

I have some beta binaries ready. Please give them a try:

   - mac 
   - windows 

It is just a better version of 0.17, so you should be able to install and
just have things be nicer. If you try it and want to go back to 0.17, just
run the installers here . The most recent one
takes precedence.

I'm hoping to do a relatively quite announcement on twitter tomorrow, so
let me know if you run into any problems!

-- 
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: Has elm reactor 0.17 dropped support for HTML files?

[Stuart Axon]

Hi,
   I just started with elm and this is a bit confusing.   - I guess I need 
a separate http server for now to see the output ?

So workflow - is:

Compile, then refresh browser that is pointing at separate http server?

S



On Sunday, May 15, 2016 at 9:57:26 PM UTC+1, John Orford wrote:
>
> Yeh the manual compiles are irksome
>
> Paul D  schrieb am So., 15. Mai 2016 
> 17:07:
>
>> It's not just serving the files, it's also debugging. It'd be pretty sad 
>> if embedding Elm meant that you couldn't use its main (sole?) development 
>> tool. I'm glad to hear that HTML support is coming back!
>>
>>
>> On Sunday, May 15, 2016 at 3:16:07 AM UTC-6, John Watson wrote:
>>>
>>> Don't worry - I'm quite happy just serving it with Apache.
>>>
>>> On Sunday, 15 May 2016 01:29:06 UTC+1, Evan wrote:

 It's probably a mistake in how I added the "pretty" view. Like I've 
 been saying to everyone about reactor, I needed to release without 
 *everything* or I'd never get 0.17 out the door. Things will be fixed 
 up later!

 On Sat, May 14, 2016 at 8:11 AM, John Watson  
 wrote:

> elm-reactor --version gives 0.17.0.  I'm running 64-bit Ubuntu.
>
> On Saturday, 14 May 2016 16:07:29 UTC+1, Joey Eremondi wrote:
>>
>> Can you verify what version of Elm reactor is being used? 
>> On May 14, 2016 2:43 AM, "John Watson"  wrote:
>>
>>> I'm affected by this, too.  If I compile with --output Main.html 
>>> then an Html file is produced with the new syntax of 
>>> Elm.Main.fullscreen(); 
>>> however elm reactor no longer serves it.  I need this to test HTTP 
>>> requests 
>>> which otherwise will give me CORS errors.  Am I missing something 
>>> obvious?
>>>
>>> On Friday, 13 May 2016 09:51:39 UTC+1, Paul D wrote:

 I'm using the fullscreen function to embed an Elm app in an HTML 
 file. With Elm 0.16, I could run elm-reactor and then go to 
 http://localhost:8080/myfile.html to use the app. After upgrading 
 to Elm 0.17, elm-reactor no longer serves the HTML. Instead it just 
 displays the file contents, much like view source would. Is this a bug 
 or 
 was that functionality deliberately removed?

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

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

[elm-discuss] Re: Communicating from parent to child and child to parent

[Brian Hicks]

The kind of message you describe in your example is definitely something 
that should be owned by the parent. It has more to do with the parent 
component than the child. It could definitely be moved to the child with a 
name change though. "Retire" or something like that.

The motivation of having the OutMsg on the child in general is to allow 
reuse of the child components. Take a "card" component, for example: you 
might have multiple components with varying content, but all producing the 
same message. You might also be using the component in multiple places. In 
that case, you would have to define the OutMsg on the child anyway, since 
otherwise you'd have a conflict between returning ParentA.InMsg and 
ParentB.InMsg.

There are multiple ways to structure this, but my experience tells me that 
the child should own all messages it consumes and produces.

On Tuesday, June 28, 2016 at 5:12:23 AM UTC-5, Wouter In t Velt wrote:
>
> 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: 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.