[elm-discuss] Re: Design concepts. Too many Msg's?

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

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

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

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

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

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

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,

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

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

[elm-discuss] elm-http-builder 5.0.0

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

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

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

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

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

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

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?

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

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

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

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

[elm-discuss] Re: Introducing Firestorm - An Elm-powered forum engine built atop Elixir and Phoenix

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

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

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

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

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

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

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

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

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

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

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

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

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:

Re: [elm-discuss] Weird bug where messages passed to the wrong 'component'

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

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

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