Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Desmond D'Souza]

On Wednesday, December 14, 2016 at 1:30:48 PM UTC-6, Rupert Smith wrote:
>
> On Wednesday, December 14, 2016 at 6:00:14 PM UTC, Desmond D'Souza wrote:
>>
>> I would love to be able to make synchronous functional calls to js and 
>> get a Result back.
>>
>
> Would you want to publish this code to elm-package?
>

Yes. 
 

>
> Would the javascript your package calls be included in the package? 
>

I don't know, but do have a naive answer. If I had written all of it in 
Elm, split into App.elm and GraphLayout.elm, I could publish both modules 
bundled into a single package or split into two, and Elm + elm-package 
spells out what a *package user* needs to know and do in both cases. If 
GraphLayout is in javascript, the overall package story should stay as 
close as reasonably possible *for the package user, *and Elm + elm-package 
should spell out what that user needs to know and do.

-- 
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: Stance on native APIs for 0.18?

[Desmond D'Souza]

On Wednesday, December 14, 2016 at 12:18:01 PM UTC-6, Joey Eremondi wrote:
>
> Sure, I could abuse it to call a stateful js ap
>
>
> Which you can currently do with Cmd ports! We'd just want to wrap it in 
> some type like Task or Cmd, and then it would be nicely segregated from 
> pure code. 
>

Correct. I phrased that badly, I meant

 "*Sure, I could call supposedly pure js code to compute a value, but that 
js happens to have some unintended side effect or stateful behavior, 
causing problem if the Elm compiler ...*".

 
Task or Cmd would still be the right way to do all *intentional* side 
effects or communication. But calling some js loaded in the browser right 
alongside my Elm code to synchronously compute *layout(graph) *should be 
handled as similarly as possible to doing all the computation in Elm 
itself. 
 

>
> On Wed, Dec 14, 2016 at 10:00 AM, Desmond D'Souza  > wrote:
>
>> I would love to be able to make synchronous functional calls to js and 
>> get a Result back. 
>>
>> Taking simple clean synchronous functional code (e.g. if it were all in 
>> Elm), and being forced to chop out bits into async calls with async Msg 
>> callbacks (just because it is not all in Elm) impacts my code in unpleasant 
>> ways: 
>>
>>1. weird async bugs: will my originally sync call to *layout(graph)* get 
>>the layout answer back *after *the user has switched to another graph?
>>2. pollution of model and update: 
>>   - I need to stuff into my model bits that were simple transient 
>>   local variables before, and maintain those extra bits everywhere in my 
>>   code. Forget to clear them somewhere, and chunks of my code like 
>> another 
>>   update branch or a view function, think I have a current graph waiting 
>> for 
>>   a layout.
>>   - I add more checks into my update to deal with possibly getting 
>>   intervening unrelated async inputs
>>   3. API bloat: why does *AndHereIsYourLayoutBack* need to be part 
>>of my API, when that is already explicit through the outgoing call 
>>mechanism (e.g. via something like a synchronous port, or some 
>> alternative)
>>
>> I think #1 would be somewhat alleviated by synchronous tasks from this 
>> thread 
>> ,
>>  
>> but #2 and #3 remain. 
>>
>> Properly supporting this use case would be good for Elm. Sure, I could 
>> abuse it to call a stateful js api, causing problems if the Elm compiler 
>> moves expression evaluation order around, hence I use some *unsafe* marker 
>> either as an annotation to myself or to the compiler.
>>
>>
>> On Wednesday, December 14, 2016 at 4:48:06 AM UTC-6, Rupert Smith wrote:
>>>
>>>
>>>
>>> On Tuesday, December 13, 2016 at 3:42:23 PM UTC, Joey Eremondi wrote:

 the elm package repo would very quickly get poluted with js code that 
> causes runtime exceptions


 But, Tasks have error handling built into them. We could do something 
 similar with synchronous code, just catch any exceptions thrown, and treat 
 the value in Elm as something like a Result.

>>>
>>> > the elm package repo would very quickly get poluted with js code that 
>>> causes runtime exceptions _* and is not portable *_
>>>
>>> Result would work, but the not portable bit is equally impoertant.
>>>  
>>>
>> -- 
>> 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: Introducing Firestorm - An Elm-powered forum engine built atop Elixir and Phoenix

[Oliver Searle-Barnes]

I thought the concept was great in the first place so I ponied up a while 
back. I would have gladly paid just for the exploration of webcomponents 
though, very much looking forward to seeing that :)

On Wednesday, 14 December 2016 20:41:05 UTC+1, Josh Adams wrote:
>
> tl;dr
>
> DailyDrip is building an open-source forum engine with an Elm frontend. 
>  We’re doing it via a Kickstarter campaign that has just 8 days remaining 
> .  We’d love your support!  More details below.
> Details
>
> [image: firestorm.jpg]
>
> There isn’t a good alternative to Google Groups for forums, and there 
> should be an easy open source alternative for comment systems.  An Elm 
> frontend is a no-brainer.
>
> The Kickstarter closes on December 22. Starting in January we will spend 
> the first month doing weekly design and planning meetings with our 
> supporters. We will also share the plans and designs along the way. We 
> would love feedback on the project early on from our backers.  After the 
> design process we’ll spend a few weeks building out the initial backend and 
> basic HTML views. We want Firestorm to be accessible to people that don’t 
> know Elm, just want a good Phoenix example application, or don’t enable 
> JavaScript. After the backend and API are completed, we will build an Elm 
> interface that replaces the existing HTML and provides a richer experience 
> to the end user as a Single Page Application. 
>
> [image: phoenix_and_elm.png]
>
> We plan on building Firestorm using Web Components - my recent experiments 
> with them have been extremely promising and should be a really modular way 
> to build out the front end.
>
> You can find more details at the Kickstarter campaign site 
> .
>
> Thanks!
>
> Josh Adams
> Co-Founder, DailyDrip
>

-- 
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: What do you think Elm's biggest shortcomings are when it comes to natively supported API's?

[W. Brian Gourlie]

Doesn't elm already have Futures in the form of Tasks?

On Wed, Dec 14, 2016 at 4:42 PM Chris Van Vranken 
wrote:

> 1) Futures
> 2) Binary data
> 3) Audio
>
>
> On Saturday, December 10, 2016 at 5:03:08 PM UTC-5, W. Brian Gourlie wrote:
>
> I've noticed a fair amount of discussion around various shortcomings of
> Elm's native libraries. Particular examples that affect me are the limited
> Websocket API and no native typed-array implementation.  The former is
> limits me quite a bit, while the latter is simply a nice-to-have. I've seen
> clamoring for file upload support as well. In any event, it would be
> interesting to get an idea of what people feel are the Elm's biggest
> shortcomings in terms of natively supported features.
>
> One thing that is frustrating as an Elm user is feeling in the dark when
> it comes to feature requests. I know the team likes to batch their efforts,
> but it's disheartening to see something sit for months unanswered. I'm
> hoping for two things to come out of this post: Get an idea of what the
> biggest pain points are in terms of natively supported API's, and to get an
> idea of what the Elm devs think. Any feedback really would be nice!
>
> Brian
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/ezErnwbsNOI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[elm-discuss] Re: What do you think Elm's biggest shortcomings are when it comes to natively supported API's?

[Chris Van Vranken]

1) Futures
2) Binary data
3) Audio

On Saturday, December 10, 2016 at 5:03:08 PM UTC-5, W. Brian Gourlie wrote:
>
> I've noticed a fair amount of discussion around various shortcomings of 
> Elm's native libraries. Particular examples that affect me are the limited 
> Websocket API and no native typed-array implementation.  The former is 
> limits me quite a bit, while the latter is simply a nice-to-have. I've seen 
> clamoring for file upload support as well. In any event, it would be 
> interesting to get an idea of what people feel are the Elm's biggest 
> shortcomings in terms of natively supported features.
>
> One thing that is frustrating as an Elm user is feeling in the dark when 
> it comes to feature requests. I know the team likes to batch their efforts, 
> but it's disheartening to see something sit for months unanswered. I'm 
> hoping for two things to come out of this post: Get an idea of what the 
> biggest pain points are in terms of natively supported API's, and to get an 
> idea of what the Elm devs think. Any feedback really would be nice!
>
> Brian
>

-- 
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: Stance on native APIs for 0.18?

['Rupert Smith' via Elm Discuss]

On Wednesday, December 14, 2016 at 6:00:14 PM UTC, Desmond D'Souza wrote:
>
> I would love to be able to make synchronous functional calls to js and get 
> a Result back.
>

Would you want to publish this code to elm-package?

Would the javascript your package calls be included in the package? 

-- 
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: Stance on native APIs for 0.18?

[Joey Eremondi]

>
> Sure, I could abuse it to call a stateful js ap


Which you can currently do with Cmd ports! We'd just want to wrap it in
some type like Task or Cmd, and then it would be nicely segregated from
pure code.

On Wed, Dec 14, 2016 at 10:00 AM, Desmond D'Souza 
wrote:

> I would love to be able to make synchronous functional calls to js and get
> a Result back.
>
> Taking simple clean synchronous functional code (e.g. if it were all in
> Elm), and being forced to chop out bits into async calls with async Msg
> callbacks (just because it is not all in Elm) impacts my code in unpleasant
> ways:
>
>1. weird async bugs: will my originally sync call to *layout(graph)* get
>the layout answer back *after *the user has switched to another graph?
>2. pollution of model and update:
>   - I need to stuff into my model bits that were simple transient
>   local variables before, and maintain those extra bits everywhere in my
>   code. Forget to clear them somewhere, and chunks of my code like another
>   update branch or a view function, think I have a current graph waiting 
> for
>   a layout.
>   - I add more checks into my update to deal with possibly getting
>   intervening unrelated async inputs
>   3. API bloat: why does *AndHereIsYourLayoutBack* need to be part of
>my API, when that is already explicit through the outgoing call mechanism
>(e.g. via something like a synchronous port, or some alternative)
>
> I think #1 would be somewhat alleviated by synchronous tasks from this
> thread
> ,
> but #2 and #3 remain.
>
> Properly supporting this use case would be good for Elm. Sure, I could
> abuse it to call a stateful js api, causing problems if the Elm compiler
> moves expression evaluation order around, hence I use some *unsafe* marker
> either as an annotation to myself or to the compiler.
>
>
> On Wednesday, December 14, 2016 at 4:48:06 AM UTC-6, Rupert Smith wrote:
>>
>>
>>
>> On Tuesday, December 13, 2016 at 3:42:23 PM UTC, Joey Eremondi wrote:
>>>
>>> the elm package repo would very quickly get poluted with js code that
 causes runtime exceptions
>>>
>>>
>>> But, Tasks have error handling built into them. We could do something
>>> similar with synchronous code, just catch any exceptions thrown, and treat
>>> the value in Elm as something like a Result.
>>>
>>
>> > the elm package repo would very quickly get poluted with js code that
>> causes runtime exceptions _* and is not portable *_
>>
>> Result would work, but the not portable bit is equally impoertant.
>>
>>
> --
> 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] Re: Stance on native APIs for 0.18?

[Desmond D'Souza]

I would love to be able to make synchronous functional calls to js and get 
a Result back. 

Taking simple clean synchronous functional code (e.g. if it were all in 
Elm), and being forced to chop out bits into async calls with async Msg 
callbacks (just because it is not all in Elm) impacts my code in unpleasant 
ways: 

   1. weird async bugs: will my originally sync call to *layout(graph)* get 
   the layout answer back *after *the user has switched to another graph?
   2. pollution of model and update: 
  - I need to stuff into my model bits that were simple transient local 
  variables before, and maintain those extra bits everywhere in my code. 
  Forget to clear them somewhere, and chunks of my code like another update 
  branch or a view function, think I have a current graph waiting for a 
  layout.
  - I add more checks into my update to deal with possibly getting 
  intervening unrelated async inputs
  3. API bloat: why does *AndHereIsYourLayoutBack* need to be part of 
   my API, when that is already explicit through the outgoing call mechanism 
   (e.g. via something like a synchronous port, or some alternative)

I think #1 would be somewhat alleviated by synchronous tasks from this 
thread 
, 
but #2 and #3 remain. 

Properly supporting this use case would be good for Elm. Sure, I could 
abuse it to call a stateful js api, causing problems if the Elm compiler 
moves expression evaluation order around, hence I use some *unsafe* marker 
either as an annotation to myself or to the compiler.


On Wednesday, December 14, 2016 at 4:48:06 AM UTC-6, Rupert Smith wrote:
>
>
>
> On Tuesday, December 13, 2016 at 3:42:23 PM UTC, Joey Eremondi wrote:
>>
>> the elm package repo would very quickly get poluted with js code that 
>>> causes runtime exceptions
>>
>>
>> But, Tasks have error handling built into them. We could do something 
>> similar with synchronous code, just catch any exceptions thrown, and treat 
>> the value in Elm as something like a Result.
>>
>
> > the elm package repo would very quickly get poluted with js code that 
> causes runtime exceptions _* and is not portable *_
>
> Result would work, but the not portable bit is equally impoertant.
>  
>

-- 
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: Should and so on be part of Html?

['Rupert Smith' via Elm Discuss]

On Wednesday, December 14, 2016 at 5:21:22 PM UTC, Rupert Smith wrote:
>
> Working with elm-server-side-renderer too, now that I pulled the latest 
> code from there.
>

Actually, an exciting moment for me, just getting my first handlebars 
templates converted over to Elm and seeing the results come up correctly in 
my browser for the first time. Another write up, once I get the code all 
cleaned up and make a nice example for others who may want to try it. 

-- 
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: Should and so on be part of Html?

['Rupert Smith' via Elm Discuss]

On Wednesday, December 14, 2016 at 5:16:45 PM UTC, Peter Damoc wrote:
>
>
>
> On Wed, Dec 14, 2016 at 6:18 PM, 'Rupert Smith' via Elm Discuss <
> elm-d...@googlegroups.com > wrote:
>
>> Html.node "meta"
>> [ attribute "charset" "utf-8" ]
>> [] 
>>
>> Outputs  with no attributes. Could be a bug in the 
>> elm-server-side-renderer code though.
>>
>> I just check this in http://elm-lang.org/try and it works as expected. 
>

Working with elm-server-side-renderer too, now that I pulled the latest 
code from there.

The question of whether these things should be a part of Html is about 
completeness, so it covers all of Html not just a subset. It is harder to 
see any of them being usefull in client side apps, but perhaps they might 
be. To come up with a contrived example, suppose I wrote an app to help 
teach Html, I might want to make use of Html to render some Html example 
which would then be escaped and pretty printed for the user.

Not such a big deal to write my own 'node' functions to cover them though. 
I'll put it in its own pure Elm package so it can be shared.

-- 
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: Should and so on be part of Html?

[Peter Damoc]

On Wed, Dec 14, 2016 at 6:18 PM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> Html.node "meta"
> [ attribute "charset" "utf-8" ]
> []
>
> Outputs  with no attributes. Could be a bug in the
> elm-server-side-renderer code though.
>
> I just check this in http://elm-lang.org/try and it works as expected.

here is the code I used:

import Html exposing (..)
import Html.Attributes exposing (attribute)


main =
node "html" []
[node "meta"
   [ attribute "charset" "utf-8" ]
[]
, node "body" []
  [div [] [text "hello"]]
]



-- 
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] Re: Should and so on be part of Html?

['Rupert Smith' via Elm Discuss]

On Wednesday, December 14, 2016 at 4:32:53 PM UTC, Noah Hall wrote:
>
> Yes, you can use `Html.node` for those. You might be better to 
> wrapping it with that stuff yourself outside of Elm though.
>

Doesn't seem to render correctly (missing attributes), but perhaps that was 
expected from those failing tests. I think you may committed fixes 
recently, so I'll try the latest from GitHub, 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.

Re: [elm-discuss] Re: Should and so on be part of Html?

[Noah Hall]

Yes, you can use `Html.node` for those. You might be better to
wrapping it with that stuff yourself outside of Elm though.

On Wed, Dec 14, 2016 at 5:18 PM, 'Rupert Smith' via Elm Discuss
 wrote:
> On Wednesday, December 14, 2016 at 3:50:29 PM UTC, Rupert Smith wrote:
>>
>> The html elements  do not have
>> counterparts in the Html module, but they are part of Html. It does not
>> usually make sense to need them in Elm, since you tend to run Elm within the
>> Html  as fullscreeen or attach it to a DOM node deeper within the
>> body.
>>
>> For complete server side rendering, it does make sense to have build these
>> Html elements within Elm.
>>
>> Should they be added to the Html module?
>>
>> Or should I just write my own set of functions, I think using Html.node it
>> will be possible to make this work?
>
>
> Html.node "meta"
> [ attribute "charset" "utf-8" ]
> []
>
> Outputs  with no attributes. Could be a bug in the
> elm-server-side-renderer code 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.

-- 
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-http-builder 5.0.0

[Luke Westby]

Hey friends!

I released HttpBuilder 5.0.0 just now. Explanation of changes is 
at https://github.com/lukewestby/elm-http-builder/releases/tag/5.0.0

Practically speaking though, even though this is a major version bump, you 
shouldn't have to change your code at all. All the function signatures are 
the same, it's just that the RequestBuilder type is not opaque anymore so 
you can write tests against it and stuff.

Thanks!
Luke

-- 
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: Should and so on be part of Html?

['Rupert Smith' via Elm Discuss]

On Wednesday, December 14, 2016 at 3:50:29 PM UTC, Rupert Smith wrote:
>
> The html elements  do not have 
> counterparts in the Html module, but they are part of Html. It does not 
> usually make sense to need them in Elm, since you tend to run Elm within 
> the Html  as fullscreeen or attach it to a DOM node deeper within the 
> body.
>
> For complete server side rendering, it does make sense to have build these 
> Html elements within Elm.
>
> Should they be added to the Html module?
>
> Or should I just write my own set of functions, I think using Html.node it 
> will be possible to make this work?
>

Html.node "meta"
[ attribute "charset" "utf-8" ]
[] 

Outputs  with no attributes. Could be a bug in the 
elm-server-side-renderer code 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] Should and so on be part of Html?

['Rupert Smith' via Elm Discuss]

The html elements  do not have 
counterparts in the Html module, but they are part of Html. It does not 
usually make sense to need them in Elm, since you tend to run Elm within 
the Html  as fullscreeen or attach it to a DOM node deeper within the 
body.

For complete server side rendering, it does make sense to have build these 
Html elements within Elm.

Should they be added to the Html module?

Or should I just write my own set of functions, I think using Html.node it 
will be possible to make this 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.

[elm-discuss] Re: What do you think Elm's biggest shortcomings are when it comes to natively supported API's?

[Rex van der Spuy]

Oh, one more important thing: Touch.
Ideally, if we just had access to a universal Pointer (that applies to both 
touch and mouse) that would be perfect.

-- 
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] Weird bug where messages passed to the wrong 'component'

[Mark Hamburg]

I was dealing with a case where a textfield from a login screen would blur 
after the screen had been removed and replaced by the main content. (Literally. 
I was looking at the new content.) The blur message would get tagged as headed 
for the content area which would then lead to a crash when the message wasn't 
understood.

My fix was to put an Html.Keyed at the top of the tree to reflect what state 
the app was in. (And then in a bit of paranoia, I looked for other, similar 
places further down and added Html.Keyed protection there as well.)

Mark

> On Dec 13, 2016, at 10:24 PM, Simon  wrote:
> 
> Thanks, I suspected that keyed would be part of the solution.
> Any sense on whether I need to apply it only to the components being left 
> (easy) with no need on those that the code is switching to (much leasy in my 
> case)?
> 
> 
>> On Wednesday, 14 December 2016 03:55:29 UTC+1, Mark Hamburg wrote:
>> I just dug into what I think is essentially the same bug. My guess was that 
>> textfields were getting removed from the DOM and then firing their blur 
>> events up through the event mapping chain — which had been updated to match 
>> the new view tree structure. It's on my list to try to build a small example 
>> of the bug after my team gets through its next milestone.
>> 
>> In the meantime, I worked around this by making fairly aggressive use of 
>> Html.Keyed to prevent pieces of the DOM from being reused.
>> 
>> Mark
>> 
>>> On Dec 13, 2016, at 9:56 AM, Simon  wrote:
>>> 
>>> Sorry about using the C word!
>>> 
>>> I had an error several months ago (0.16/0.17) where the wrong data would be 
>>> attached to message, causing all sorts of weirdness. It happened after a 
>>> successful logon and as the App tried to redirect to the main view. I have 
>>> a vague feeling that in the end all I needed to do was update 
>>> elm-lang/virtual-dom.
>>> 
>>> Anyway, it has come back. It has something to do with when the browser puts 
>>> in login information for you. I can create the error by deleting the 
>>> auto-input and inserting my password and clicking enter to submit.
>>> 
>>> Then what I see in my logs is this message
>>> 
>>> `User.SwitchGroup: Blur "password"`
>>> 
>>> Whereas SwitchGroup has type `String -> Msg` and `Blur "password"` are 
>>> artefacts of the elm-form library that was used in the Login component and 
>>> is not used in the User one.
>>> 
>>> Does this remind anyone of something they have experienced, solved, and 
>>> remembered how they solved it?
>>> 
>>> -- 
>>> 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.

-- 
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: Stance on native APIs for 0.18?

['Rupert Smith' via Elm Discuss]

On Tuesday, December 13, 2016 at 3:42:23 PM UTC, Joey Eremondi wrote:
>
> the elm package repo would very quickly get poluted with js code that 
>> causes runtime exceptions
>
>
> But, Tasks have error handling built into them. We could do something 
> similar with synchronous code, just catch any exceptions thrown, and treat 
> the value in Elm as something like a Result.
>

> the elm package repo would very quickly get poluted with js code that 
causes runtime exceptions _* and is not portable *_

Result would work, but the not portable bit is equally impoertant.
 

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

[Manu Rosa]

Cheers Wouter! That's going to come in very handy. Great example of an app 
that's grown in complexity.

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.