[elm-discuss] Literature review of requested features

I'm salvaging this idea from the "moving on" thread. Basically, some features like audio playback, binary data, task ports, and so on have been commonly requested. I'd like to propose that the advocates of these features do some of the pre-code legwork. This is more of a literature review than

Re: [elm-discuss] Re: Moving on

This thread is really good imho. Uncomfortable? Perhaps. But everyone here has good intentions. >From my POV Elm ain't your usual throw-things-at-the-wall and see what sticks open source project, which is what makes it very very special. And therefore perhaps the community and our BDFL need to

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

Also, have you seen elm-plot? https://terezka.github.io/elm-plot/ I haven't played with it yet, but it looks pretty neat. Might help with some of your features that used highcharts? Dustin Sent from my iPhone > On Apr 30, 2017, at 8:10 PM, Dwayne Crooks wrote: >

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

Ah, your version is way better！Love the groupBy function.  Cheers! Dustin Sent from my iPhone > On Apr 30, 2017, at 8:10 PM, Dwayne Crooks wrote: > > I posted here as the other thread seems to be closed off from replies. > > For this particular app I'm

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

I posted here as the other thread seems to be closed off from replies. For this particular app I'm writing/porting the SPA from scratch to Elm and the formatting issue was the first small hiccup I ran into. As suggested in the other thread I went ahead and wrote the code I needed in Elm. Here

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

Noah, just re-read the Dwayne's original post. He has some app in React and he's trying Elm to replace it. One of his first bump was the little, (trivial maybe) issue with formatting. He's used to use that very library for it and the question was how should the integration look like. Using ports

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

Witold, that's a ridiculous response. Please re-read my reply. Without fully knowing the context of the problem, you suggested using Native. This is not something we encourage in the Elm community. There are valid reasons as to why not. When recommending it, is it best to know _everything_ about

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

Noah is always right. He's just a Elm Rock Star, he knows the best. is that realy what be said to me or did I miss the point? I have no idea what I was thinking when I dreaded to "lecture" him. Oh, by the way, Dwayne's attempt to follow those golden rules failed. He must have missed something

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

Noah is right. You don't want to reach for Native for this type of integration. If this can't be smoothly integrated with ports (we've all felt that pain), the next best option is to write the elements of the plug-in that you need in elm. On Sunday, April 30, 2017 at 1:37:04 PM UTC-4, Noah

[elm-discuss] Re: Discovery: Model /= Database

The pattern we use is to have our Page.update functions return (model, cmd, storeCmd) the main update then applies the storeCmd to the Store. (the actual code supports a few other things but that's the basic gist of it). Hit me up on slack if you want to chat about it. On Sunday, 30 April

Re: [elm-discuss] Re: Moving on

On Apr 30, 2017, at 8:43 AM, Max Goldstein wrote: > > Fourth, web components were briefly mentioned. Richard gave a talk on these > last year and it seems like everything you need already works. Specifically, on this, no. The virtual DOM API does not make the sort of

Re: [elm-discuss] Re: Moving on

> > First, I'm going to call out the air of ungratefulness and animosity in > this thread. Evan is giving you software for free, and it's software that's > good enough that you invest your time into writing it and commenting about > it. > Just to be clear, in case this is directed at me in

Re: [elm-discuss] Re: Moving on

> > I'm going to call out the air of ungratefulness and animosity in this > thread. Evan is giving you software for free, and it's software that's good > enough that you invest your time into writing it and commenting about it. > You should not expect Elm to move at the same pace as Angular

Re: [elm-discuss] Re: Moving on

This thread is too long to be productive. Please make a new thread, if you wish to continue the discussion here, with a relevant title to the particular part of this conversation you wish to continue in. When a thread gets long like this, hitting multiple topics, it's hard for anyone but those

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

Witold, with all due respect, I am one of the people who has written the _most_ Native code. I know a thing or two about it. You do not need to lecture me, and my warning should be heeded. Like I said, there are _some_ cases where a Native binding makes sense. They are few and far between. These

[elm-discuss] Re: Ports seem contrived when trying to format a value as money

Hi Dwayne, I'm not sure how complex your currency formatting needs are. But I think you should be able to do a lot of this yourself in Elm—especially if all you're looking for is commas and dollar signs. I threw together an Ellie app to get you started. https://ellie-app.com/34vgDLqvmd6a1/1

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

Noah, this is exactly the kind of problem to be solved by native binding. Dwayne wants to use his formatting library. This is a classic example of pure function. Nothing is going to crash if you wrap exception in Result and check types. Good advices of self reimplementig everything from scratch

[elm-discuss] Re: Moving on

Folks. I feel this thread is maybe not the best place to discuss certain details of topics that raised in discussion. I feel there are too much topic being actively discuss right now and it starts to be pretty hard to follow everything. I feel that understanding what others are talking about

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

Witold, this it not the advice that we give to people exploring such problems in Elm. There are many reasons why Native bindings are bad. A single error in your JS will cause the _entire_ application to crash unrecoverably. Wrapping things as a result will not help you catch those errors. Writing

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

Ports and subscriptions are for executing actions with effects, in my opinion. Native bindings for pure functions are nothing bad. Just keep away from exceptions, use Result in case of possible troubles. 30.04.2017 4:00 PM "Dwayne Crooks" napisał(a): > Thanks guys. > >

Re: [elm-discuss] Re: Moving on

Just to play devil's advocate for a moment; Despite my suggestion, and as much as I'm an advocate for package curation I don't think that it's the right first step towards solving the problem. In my opinion the realistic solution is one that may already have been discussed in the past: 1.

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

Thanks guys. I explored Noah's approach to see how the solution would turn out. But I didn't like it. The code change required to format a list of floats as money is ridiculous. Here's what I started with https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-0-start-elm. And

Re: [elm-discuss] Re: Moving on

I think if we are working on the basis of a blessed set of modules one of the requirements should be having several people who can merge a pull request etc. Zach ᐧ On Thu, Apr 27, 2017 at 1:48 PM, Rehno Lindeque wrote: > > This grey list would be backed by a clear

[elm-discuss] Re: Discovery: Model /= Database

I think I've just had an aha moment with this post. I am in the process of refactoring my monolith MUV into separate modules with their own MUV for each "page" of my SPA. Up to this point, I have had a separate Store module with its own Model and Msg types and an update function (no view,