Re: [elm-discuss] Re: Design of Large Elm apps

> > How big do the case statements in your update functions get? Or are your > pages just not that complex? > > I tend to like to keep modules in any language to a size that can be > reasonably read and comprehended. That doesn't always happen. I've written > some behemoths. But I tend to feel

[elm-discuss] Re: [ANN] elm-mdl 7.0.0 — supports all components of Material Design Lite

Does Google's MDL spec include the concept of clickable images? I need to present a multi-lingual site where the language is changed by clicking on a small PNG flag. It's easy to do in elm-html .. img [ src ("UK.png"),flagstyle, onClick English] [] .. .. but I don't see in in the MDL spec or

Re: [elm-discuss] Re: Design of Large Elm apps

How big do the case statements in your update functions get? Or are your pages just not that complex? I tend to like to keep modules in any language to a size that can be reasonably read and comprehended. That doesn't always happen. I've written some behemoths. But I tend to feel guilty when

[elm-discuss] Re: [ANN] elm-mdl 7.0.0 — supports all components of Material Design Lite

Does Google's MDL spec include the concept of clickable images? I need to present a multi-lingual site where the language is changed by clicking on a small PNG flag. It's easy to do in elm-html .. img [ src ("UK.png"),flagstyle, onClick English] [] .. .. but I don't see in in the MDL spec or

[elm-discuss] Re: about the Keyboard API

You did change the behavior, though. Specifically, AnimationFrame.ticks is always running in your version, even when the game is paused. Similarly for some of the other subscriptions. As discussed in the generic subscription filtering thread, it's best to turn off subscriptions completely whenever

Re: [elm-discuss] elm-lang.org's Framework

Elm is frontend only, so Haskell is what's running on the back end and actually serving the HTML and js. As for framework, I think it's using Snap as a Haskell Web framework. So, I'm looking at elm-lang.org's source ( github.com/elm-lang/elm-lang.org ), and I see that very little of its code is

[elm-discuss] Chaining and Task with a Port request

I often feel the same. The "just use ports" argument frustrates me when ports, unlike tasks, just don't compose. Eg a hypothetical readSessionFromLocalStorage `Task.andThen` makeAPIRequest Function which, because local storage isn't available in Task form (Yet) turns into a 2 stage thing in

Re: [elm-discuss] Re: about the Keyboard API

Yeah they would be useful. I went ahead and tried my hand at editing the code a bit to make it what I think is more readable, although the entire project gets formatted exceedingly differently if elm-format is run over it, so I did not and followed the existing style. I'd not messed with a

Re: [elm-discuss] Re: about the Keyboard API

I like the proposed changes to keyboard API, they would definitely make my life easier. Also, that is the level where I want to do filtering in this case: as close to the event source as possible. Since the idea is that I am not interested in a bunch of events: I do not want them to be sent to

Re: [elm-discuss] Re: about the Keyboard API

For actual subscription filters that I am using I have a lot of ports Yes, I can see that that would be an additional case. Ports have not been on my radar, since they were not relevant to the projects considered. So Keyboard and ports. For ports, that could motivate a similar change, where

[elm-discuss] Rust's new error messages cite Elm as inspiration

https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html -- 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

Re: [elm-discuss] Re: about the Keyboard API

Ah entirely replace them Yes, that’s what I proposed in an earlier message in this thread. An action manager like mentioned above could make it very easy then, especially if it was a state-based action mapper as is common in many windowing systems. An action manager would be something else, and

Re: [elm-discuss] Re: about the Keyboard API

On Wednesday, August 10, 2016 at 12:20:46 PM UTC-6, Daniel Bachler wrote: > > I like your general solution, OvermindDL1, but I don't think it is > mutually exclusive with improving the keyboard api as Janis suggested. For > general cases, your solution is great. But as several people already

Re: [elm-discuss] Re: about the Keyboard API

I don’t understand your concern. The Keyboard API would not get larger, because I have proposed to replace three old functions by three new functions. The rest of your concerns build on that concern (ballooning), so seem immaterial to me at the moment. Let’s judge the proposed change to the

Re: [elm-discuss] Re: about the Keyboard API

I like your general solution, OvermindDL1, but I don't think it is mutually exclusive with improving the keyboard api as Janis suggested. For general cases, your solution is great. But as several people already said, with Keyboard it is practically always the case that you want to filter, ergo it

Re: [elm-discuss] Re: about the Keyboard API

On Wednesday, August 10, 2016 at 11:51:36 AM UTC-6, Janis Voigtländer wrote: > Okay, saw this only after sending my previous message. Still, the > FilterOnly message to be handled in update functions now is like a return > of the NothingHappened message that I was so happy to have eliminated.

Re: [elm-discuss] Re: about the Keyboard API

Yeah I've been looking for potentially a way to have 2 message types altogether. I am leaning toward just Msg having an UpdateMsg and a FilterMsg subtypes. It would be easy to split on either then and even hoist them into their request function. On Wednesday, August 10, 2016 at 11:51:36 AM

Re: [elm-discuss] Re: about the Keyboard API

Okay, saw this only after sending my previous message. Still, the FilterOnly message to be handled in update functions now is like a return of the NothingHappened message that I was so happy to have eliminated. Plus, the filters function’s added complexity. I still stand with “I’d rather have the

Re: [elm-discuss] Re: about the Keyboard API

What will the GameMsg type look like? ​ 2016-08-10 18:59 GMT+02:00 OvermindDL1 : > > If there are alternatives *with currently available functions* to my > proposal, very interested to hear it in this thread. > > That is why I looked at more options and started thinking

Re: [elm-discuss] Re: about the Keyboard API

For note, if you want to not get HandleKeyPress messages ever it should actually be: ```elm filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model = if model.state == Running then case msg of HandleKeyboardDown c -> case Char.fromCode c ->

[elm-discuss] Re: Which text editor do you prefer for Elm?

Atom used to be *hugely* laggy when I last tried it. But I spun it up again recently for this new work project a couple months ago and it is significantly better now, very responsive (not quite as responsive as, say, KDevelop, which blows even intellij away, but fantastic now nonetheless).

[elm-discuss] Re: Which text editor do you prefer for Elm?

I've found the HTML5 based editors like Atom and Lightable a bit laggy in the past (maybe things have changed?) so for me it's Sublime all the way down :) -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop

[elm-discuss] Will server side elm be a game changer?

Is it predictable that something like 'elm rails' or 'elm express' will be developed and be a game changer on elm adoption? -- 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

Re: [elm-discuss] Re: about the Keyboard API

Generally, Nick is right, I primarily want to hear feedback about the specific API proposal I made. However, I wrote the other day that "If there are alternatives *with currently available functions* to my proposal, very interested to hear it in this thread." So since Overmind seems to since

[elm-discuss] Re: Collecting use cases for File, ArrayBuffer and TypedArrays/DataViews

I think this is the sort of code I would like to be able to write to do signed S3 uploads FileReader API readFile : FileRef -> Task Error Blob and in the Http library blobData : Blob -> Http.Data such that get ("signature" := string) "/get_signature" `Task.andThen` \sig ->

Re: [elm-discuss] Re: about the Keyboard API

My opening post discussed the API proposal here in the context of several pieces of very concrete code using Keyboard (written as student projects not for the purpose of showing a particular point about Elm, but to simply get stuff done). Please take one of them, preferably the one I elaborated

Re: [elm-discuss] Re: about the Keyboard API

That is not what this discussion is about. Janis proposed a change to the Keyboard API. The reason he started this thread was to get our thoughts on his proposal. On Wed, Aug 10, 2016 at 8:37 AM, OvermindDL1 wrote: > How is it off-topic considering its whole purpose is to

[elm-discuss] Is it possible to render an HTML form that works directly?

This is related to https://groups.google.com/forum/#!topic/elm-discuss/M6vbRoVSaG4 in that I'm trying to find work arounds to do signed uploads to S3. In short, can I use Elm to render a POST form with a `file` input and a submit button that 'just works' - i.e. the POST takes place directly

[elm-discuss] Chaining and Task with a Port request

As we have to use ports to access the FileReader API, I’m facing the situation where I want to do the equivalent of http.get ("signature" := string) "/api/signature" `Task.andThen` (\sig -> sendS3 sig) |> Task.perform where port sendS3Cmd : String -> Cmd msg Clearly this does not type

Re: [elm-discuss] Re: about the Keyboard API

How is it off-topic considering its whole purpose is to handle this exact kind of issue? The discussion is about filtering messages, potentially translating them to a a better message that is for a specific purpose without needing to worry about checking for valid input in update area. It is

[elm-discuss] Re: Which text editor do you prefer for Elm?

> Any idea how to tell linter-elm-make where to pick up the elm-package.json > from? > Go to linter-elm-make's settings and tick "Always Compile Main". -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop

Re: [elm-discuss] Re: Which text editor do you prefer for Elm?

I'm quite happy with vim & elmcast/elm-vim. In other news: I'm quite happy but :ElmFormat does not work — yes, the bin is available on my $PATH. Any ideas why? On Wed, Aug 10, 2016 at 3:58 PM Joey Eremondi wrote: > Elm-light is full of features, and actively maintained

Re: [elm-discuss] Re: Which text editor do you prefer for Elm?

Elm-light is full of features, and actively maintained by someone who is pretty active on this mailing list, which is nice. https://github.com/rundis/elm-light On Aug 10, 2016 7:56 AM, "Nick H" wrote: > I use emacs elm-mode too, and I agree that the default formatting

Re: [elm-discuss] Re: Which text editor do you prefer for Elm?

I use emacs elm-mode too, and I agree that the default formatting is super bad. But you can fix this by installing elm-format and enabling the flag elm-format-on-save. Instead of indenting the entire file, just save your work and all will be well. I haven't had any problems with crashing or

Re: [elm-discuss] Curious - Why have both Html Msg and Cmd Msg?

> > If all commands were treated equally, abstracting away these optimizations > would not be possible. > Got it. The virtual DOM diffing makes sense that this is a special case. A slight tangent to this post, I would assume that this pattern (using a separate construct for the purposes of

Re: [elm-discuss] Re: about the Keyboard API

Overmind, we can all see the thread that you started. It is still off-topic for you to bring it up here. On Wed, Aug 10, 2016 at 7:40 AM, OvermindDL1 wrote: > Well for what it is worth I made a library that can filter messages before > they are handled, so you could, for

Re: [elm-discuss] Should Color be a part of core?

The color data needs to be translated to a Vec4 before being sent to a shader. So this library isn't a particularly good fit for working with WebGL. The types were written to be used with evancz/graphics. The gradient stuff is completely unusable by anybody else, since the Gradient type is

Re: [elm-discuss] Re: about the Keyboard API

Well for what it is worth I made a library that can filter messages before they are handled, so you could, for example, turn a keypress of 'w' into a message of 'GoForward' and 's' into 'GoBackward' or whatever. And if you cancel a message then it becomes entirely unhandled and you will never

Re: [elm-discuss] How to get relative mouse coordinates

On Friday, May 20, 2016 at 5:51:16 PM UTC+1, Frederick Yankowski wrote: > > With a custom event decoder you can get relative mouse positions, by > grabbing the offsetX and offsetY fields of the event. > > >

Re: [elm-discuss] Curious - Why have both Html Msg and Cmd Msg?

> > >- Any html returned from the app are descriptions of side effects to >the DOM specifically and Elm takes care of that as well > > As Laszlo says, this is incorrect, at least conceptually. *Html Msg* means a description of HTML, independent of any existing HTML, whose events

Re: [elm-discuss] Curious - Why have both Html Msg and Cmd Msg?

Actually, Html is a very special case. Rendering the same Html multiple times will give the same result and not cause any visible side effects (even though it is it DOM manipulations underneath). This is similar to how the browser distinguishes between GET and POST requests. It allows the browser

Re: [elm-discuss] Curious - Why have both Html Msg and Cmd Msg?

I don't fully understand your explanation but that is in part due to my ignorance of the underlying implementation of both Cmd and Html. Let's see if we can discuss at a more conceptual level. Here is a snippet from the Elm examples page: getRandomGif : String -> Cmd Msg getRandomGif topic =

Re: [elm-discuss] Curious - Why have both Html Msg and Cmd Msg?

Sure, you can imagine turning a Html Msg into a Cmd Msg but if you do that you lose the information that makes it a Html Msg. If the children of a div could be any Cmd Msg, you could put an Http request there and it would type check but what would that mean? You can look at it like you would

[elm-discuss] Re: Which text editor do you prefer for Elm?

On Wednesday, August 10, 2016 at 1:19:53 PM UTC+1, Simone Vittori wrote: > > I tried Atom recently, it gets pretty good when you start using the > linter-elm-make package. You > get inline errors and some other goodies. > Any idea how to tell

[elm-discuss] Curious - Why have both Html Msg and Cmd Msg?

I can speculate as to why DOM side effects are different than all other side effects. But when explaining the Elm architecture to a friend I explained it like this: - Elm apps take in a model and a Msg as inputs and run those two inputs through an update function - The update function

[elm-discuss] Re: Which text editor do you prefer for Elm?

VS Code on one machine, Atom on another. Both very good. And Firacode as the font, of course, for those cool ligatures. -- 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

[elm-discuss] Re: Which text editor do you prefer for Elm?

I tried Atom recently, it gets pretty good when you start using the linter-elm-make package. You get inline errors and some other goodies. Anyway I've been a happy Sublime Text user for a long time now. Elm support is quite good too, I used to have

[elm-discuss] Re: Which text editor do you prefer for Elm?

I use VSCode and I'm pretty happy with it onsdag 10. august 2016 12.47.34 UTC+2 skrev Rupert Smith følgende: > > I'm trying the Elm emacs mode, but it is pretty bad. If I select and > indent a whole file for example all the import statements and statements > within a let .. in get indented +1

[elm-discuss] Re: My first Elm

On Wednesday, August 10, 2016 at 12:05:39 AM UTC+1, Ian Mackenzie wrote: > > Have you looked at the modularity section > of > the Elm guide? It doesn't yet specifically cover nesting components that > have subscriptions, but

[elm-discuss] Re: Design of Large Elm apps

Oh no, just as I make a 3-deep TEA stack in my own app and start to feel good about finally sort of figuring it out, you have to go and post this :D I don't think I've fallen into a trap.. yet.. but it wouldn't be a beginner trap if a beginner could casually avoid it, now would it? Evan's recent