[elm-discuss] Re: ELM = JAVASCRIPT REINVENTED (PART 1)

Yeah it's a bit inaccurate to say Elm is JS reinvented because Elm never used JS as a starting point.  I think there's a more plausible case to be made that Elm is "Standard ML Reinvented" - since JS is only Elm's (current) compilation target. Any ways in which Elm's design resembles JS are

[elm-discuss] Re: Would Enums make a good addition to Elm?

> > Having a deriving-esque way to generate encoders and decoders > automagically would be great, and would go a long way in solving the > hassle. (2) would also make my life easier. > The problem I see with both deriving-esque auto coders (DEAC, patent > pending) and comparable union types,

[elm-discuss] Re: Would Enums make a good addition to Elm?

> > The problem I see with both deriving-esque auto coders (DEAC, patent > pending) and comparable union types, is the difficulty of implementation. > DEAC's seem like an advanced language feature that will take a while to get > into the language. > Having talked to Evan about it, it seems

[elm-discuss] Re: Would Enums make a good addition to Elm?

> > However, strings and numbers still need to be used in production apps for > several reasons: > 1) Union Types is not supported in Json, so one needs to convert to/from > strings or numbers for communicating with other systems. > 2) Union Types are not comparable, and so cannot be used as

Re: [elm-discuss] Would Enums make a good addition to Elm?

Mark - this seems like a great addition to the error message catalog ! I've heard of people encountering this too. Seems like it should be easy enough to detect, and the compiler could either provide a concise explanation of what's going on or

Re: [elm-discuss] Re: Tour of an open-source 4,000 LoC Elm SPA

Agreed! That does sound like a useful (albeit separate) demo project. :D On Mon, May 8, 2017 at 10:03 AM Marek Fajkus wrote: >  It's clearly great contribution to educative materials around Elm. I've > seen your tweet before and was really pleased you've found time to

[elm-discuss] Re: Tour of an open-source 4,000 LoC Elm SPA

> > Can you comment on why you did not use the elm-webpack-loader? > I'm trying to understand if we are moving towards a better approach or if > there are other considerations. > It honestly did not occur to me that I might do that! If I have the choice between using Webpack and not using

[elm-discuss] Tour of an open-source 4,000 LoC Elm SPA

I get asked if there are any sizeable open-source Elm SPA examples out there...so I made one! Hope it's useful: https://dev.to/rtfeldman/tour-of-an-open-source-elm-spa -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this

[elm-discuss] Re: Poll for Intermediate to Advanced topics that people struggle with

This open-source Elm SPA uses JWT authentication...maybe it's useful? https://dev.to/rtfeldman/tour-of-an-open-source-elm-spa On Tuesday, May 2, 2017 at 1:18:56 PM UTC-7, Erik Lott wrote: > > For the folks who are struggling with authentication, are you having > issues with authentication in

[elm-discuss] Re: Error Messages can they be made more intuitive?

This is perfect for the error message catalog - if you have a sec, would you mind reposting as an issue there? Welcome to Elm! :D > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To

Re: [elm-discuss] Re: Comments on the TEA Components package

> > This isn't the first time I've seen a dev misunderstand your statement - > *Model-View-Update > triplet is the wrong unit of composition for Elm applications *- and > attempt to write an entire SPA without using a triplet. Very painful stuff. > I know that's not what you're advising, but

Re: [elm-discuss] Re: Comments on the TEA Components package

> > I feel like this discussion has covered a few different scaling techniques > and I feel like there's a good time to use all of them. Perhaps it would be > good to just catalogue the different approaches along with some examples > where people have found them useful in their projects. >

Re: [elm-discuss] Re: Comments on the TEA Components package

Thanks Oliver! That's super helpful. <3 as well as providing a fully integrated UI which includes all of the > features, we will also allow individual features to be embedded within > particular pages e.g. an article might have a discussion embedded at the > end, but that same discussion

Re: [elm-discuss] Re: Comments on the TEA Components package

> > We did spend the first 6 months or so of our project following the advice > to not use nested TEA components. Our experience was that the perceived > complexity of the app grew exponentially to the point where it was > difficult to make progress. We refactored into a nested TEA structure

Re: [elm-discuss] Re: Comments on the TEA Components package

> > Sorry again for confusing. > It's all good! :) You were super polite and respectful throughout. -- 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: Comments on the TEA Components package

> > The structure camp says (in many more words) "I've seen your alternative > and it isn't a real alternative. It's a pathway that decades of software > industry experience indicates leads to creating big balls of mud." > This idea would hold more water if people hadn't tried what you're

[elm-discuss] Re: Comments on the TEA Components package

> > > I thought I've understood this but I'm more and more confused by what > you're saying: > >> Crucially, between 0.16 and today, *we learned that a Model-View-Update >> triplet is the wrong unit of composition for Elm applications.* > > init update and subscribe are actually function.

Re: [elm-discuss] Re: Comments on the TEA Components package

> I'm curious what makes it sound that way, since as you noted, that is not >>> the point I'm making. >>> >> >> I don't know if others feels like me or not. But at least for me, "no >> components" sounds a bit confusing (it is in official guide too). >> > > I view it as destructive so,

Re: [elm-discuss] Re: Comments on the TEA Components package

> > I don't know if others feels like me or not. But at least for me, "no > components" sounds a bit confusing (it is in official guide too). As you > explained the context behind the term "component" is quite huge. I use the > word "component" just to say "reusable UI", so "no component"

Re: [elm-discuss] Re: Comments on the TEA Components package

> > You are right if everyone make their UI from scratch, but how about others > who wants to *use *existing library? For instance, date picker is a > popular widget. We expect this widget to do lot of complex things behind > the scene. But it requires state management (e.g. selected month).

Re: [elm-discuss] Re: Comments on the TEA Components package

> > I've seen agile teams that could generate lots of small changes but when > faced with needing to do something big found themselves profoundly stuck. > In Elm? the distillation of the don't use nested TEA argument when people have > asked what to do instead has tended to be "use functions"

Re: [elm-discuss] Re: Comments on the TEA Components package

> > "just write one monster model" approach > Mark, this is about the third time you've insinuated that my explanation of how to split things up

Re: [elm-discuss] Re: Comments on the TEA Components package

> > so, the Model-View-Update triplet *is NOT* the wrong unit of composition > for Elm applications? :) > > > How do you propose to split the functionality one has in a highly >> complex app with a lot of pages without using those triplets? >> >> I don't haha...I just defended their use a few

Re: [elm-discuss] Re: Comments on the TEA Components package

> How do you propose to split the functionality one has in a highly complex app > with a lot of pages without using those triplets? I don't haha...I just defended their use a few posts ago, complete with the specific example of the reusable signup form. -- You received this message because

Re: [elm-discuss] Re: Comments on the TEA Components package

scaling experience, but I honestly don't think I have much to contribute to those discussions. :) On Tue, Apr 18, 2017, 9:56 PM Peter Damoc <pda...@gmail.com> wrote: > On Wed, Apr 19, 2017 at 2:58 AM, Richard Feldman < > richard.t.feld...@gmail.com> wrote: >> >> &quo

[elm-discuss] Re: Comments on the TEA Components package

> > 2. This isn't really about defining components — a hot button word with > some people (go read the elm-dev thread) — so much as it is about defining > embeddings of one TEA-shaped unit within another. > > Side note on TEA: In Elm 0.16, TEA was all about being composable. > I really like

Re: [elm-discuss] Re: Post Examples of Painful Record Updates Here!

On Friday, March 3, 2017 at 8:45:01 AM UTC-8, Mark Hamburg wrote: > > Our codebase suffers from this as well. > Mark, can you post some examples of painful code? As in, not just what you wanted to write but couldn't, but what you ended up writing that's still painful. Real code is much more

Re: [elm-discuss] Re: Post Examples of Painful Record Updates Here!

Can we express these in terms of examples of real-world code that is currently painful? That's really the key here. :) On Fri, Mar 3, 2017, 4:18 AM 'Rupert Smith' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > Another one I have run into, is when selecting just one field from a >

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

Re-posting the first example from Franscisco's thread : There is a common pattern where a library (ex, elm-markdown) will provide a default config, to be extended by the user. Here the two ways to do this right now, one painfully

[elm-discuss] Post Examples of Painful Record Updates Here!

There have been various discussions of potential ways to improve Elm's record update syntax. Evan commented that "(examples > design work) at this point" - any potential designs for syntax improvements would need to be run through a gauntlet of examples to see how well they'd work, so the first

Re: [elm-discuss] Re: Emphasizing /r/elm more

Worth noting that the top thread on elm-discuss for several weeks has been largely about languages other than Elm, and the Elm-specific parts have primarily consisted of lobbying Evan for reprioritization through a

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

> > The reason is that BuckleScript proves that Arrays are faster than > "string" tagged objects and I have tried benchmarking it myself. In fact, > I have gone further and manually substituted the use of Arrays rather than > the string tagged objects in the generated Elm code to show that is

Re: [elm-discuss] Is Elm.worker gone in 0.17?

I really need to update that post! worker still exists, you just access it by using Platform.program . :) -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

> > you need recompile that module and regenerate a monolithic js file, the > larger project it gets , the worse compilation time you get in elm mode. If > you have experience in C++, you know the bottle neck used to be linking, it > is quite common for a c++ project to spend 20minutes in

[elm-discuss] Re: [Suggestion] Type values and simplifying the language still

Just to chime in about automatic serialization/deserialization, reading other threads, it seems the big question is what the JSON would look like. I propose this: {"tag": "Maybe.Just", "$0": 5} The tag field contains the constructor name, fully-qualified to prevent ambiguities between

[elm-discuss] Re: [Suggestion] Type values and simplifying the language still

I agree that automatic serialization/deserialization of union types is orthogonal to this idea, but I am default interested in any language simplification! Ignoring ctor implications, here are my initial thoughts on that idea on its own merits: - These union type constructors are functions

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

> > I'm wondering why the Elm compiler is so slow at parsing if that is where >>> the slow-down is >>> >> >> Evan recently rewrote the parser to be much faster. >> >> You can try a preview binary >>

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Keep in mind that code is the easy part ; the major thing standing between Elm and a different compilation target than JavaScript is 1-2 years of design work to figure out a quality user experience. > I'm wondering why the Elm compiler is so slow

[elm-discuss] Re: Intended usage of -- comments (and elm-format)

> > elm-format needs some work in this regard. > Yeah, that's all it is. :) Elm's parser throws out comments by default, so Aaron has been having to strategically re-add them in his version of the parser, in order to support them properly. He hasn't finishing covering all the cases yet. --

[elm-discuss] Re: UI effects (align/tether, scroll into view) after elements are inserted

Hi Sebastian, Elm batches DOM updat`es using requestAnimationFrame , so you should be able to delay until after the next DOM update by wrapping your entire callback (starting from let el =

[elm-discuss] Re: Emphasizing /r/elm more

> > How about using Discourse ? React forum > and Meteor forum > use > it, or you can see the list here > . > At some point I heard someone point out that /r/elm is

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

> > This comes off as an attempt to end the discussion before it begins. > Unless you know something we don't? Well, they know Evan. :) > Will Evan never consider improvements to syntax? Of course he considers improvements to syntax! > Will he refuse to read this thread? He would be

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Lawrence, please keep it civil. > > -- 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

[elm-discuss] Re: Using flat-file JSON fixtures in elm-test and API tests

Thanks for the level of detail on this! Testing that things are wired up as expected is something I'd like to add to elm-test. I hadn't thought about the "shared fixtures" angle. It's definitely interesting! I'm also curious to see if anyone else has any similar use cases, and their

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

ons in other > libraries with native modules. > > I understand the hesitation in giving a guide on an escape hatch to > native, since people will instinctively reach for it. Just was wondering if > there was new thinking on it. > > > On Monday, December 5, 2016 at 8:19:14 AM UTC-8

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

Looking at the evancz/elm-markdown parser, that seems like a case that warrants it, yeah. -- 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,

Re: [elm-discuss] Maximum call stack size exceeded while parsing generated code

Is this true only when the debugger is running? I've heard of people hitting this when the debugger is running (e.g. in elm-reactor, which always has the debugger running) but not so much with a plain old elm-make. On Saturday, December 3, 2016 at 8:01:13 PM UTC-8, Nick Hollon wrote: > > I have

Re: [elm-discuss] Re: Integrating Elm with Web Components / Polymer

Simon - video is not up yet. dedo - I haven't tried that, but try what Rupert did here - seemed to help with children of lists! On Sunday, December 4, 2016 at 1:43:08 PM UTC-8, dedo wrote: > > @Richard, I tried to use your

Re: [elm-discuss] Inter triplets communication.

> > Thank you for this example. But I don't see how to properly trigger my > "ratings" storage reload action if user state changed. However you please! The caller has the necessary User info now, so UserInfo is out of the picture and you can do whatever would normally make sense. Here's one

Re: [elm-discuss] Inter triplets communication.

> > Put another way, *Elm does not have anything similar to components!* > > But how about elm-mdl, elm-autocomplete, elm-ui, elm-datepicker, > elm-form, elm-sortable-table even spinner elm-spinner? Thay all use theirs > model, update, view "triplet" to be reusable and hide implementation >

Re: [elm-discuss] Unpublishing a package

> > What would happen if someone deletes their github repository? Wouldn't the > same kind of breakage take place? > Yep, but that's a flaw in the current implementation (which was chosen for expedience), not a desired feature of the design. The longer-term plan (which might be happening in

Re: [elm-discuss] Unpublishing a package

There is no unpublish feature, and it's important that there never be one . :) If you want to deprecate a package, I recommend publishing a new major release that removes everything and replaces the README with an explanation of how

[elm-discuss] Re: Interactive maps with Elm 0.17 : recommendation?

I have a proof of concept of using the Polymer Google Maps element in Elm: https://github.com/rtfeldman/elm-google-maps I haven't really documented what I did terribly well, and I haven't used it for a serious project, but seemed to work well...hope it's at least somewhat helpful. :) -- You

Re: [elm-discuss] Re: Integrating Elm with Web Components / Polymer

FYI I got Google Maps working based on Fred's calendar repo: https://github.com/rtfeldman/elm-google-maps -- 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: Inter-Component Communication in 0.17

Oh man, now I feel like a total jerk for my harsh tone. My apologies, and thank you for the update Erik! <3 -- 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] Why aren't doc PRs merged?

Evan's elm-conf keynote may help clear up some of the "why" questions. :) https://www.youtube.com/watch?v=DSjbTC-hvqQ -- 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

Re: [elm-discuss] Re: Integrating Elm with Web Components / Polymer

Has anyone gotten anything doing really complicated DOM stuff (in particular Google Maps comes to mind) working in Elm via web components? In theory it would Just Work, but in practice I always wonder... ;) On Mon, Oct 10, 2016 at 5:40 PM Peter Damoc wrote: > using attached

[elm-discuss] Re: Is over-use of 'let... in' considered an anti-pattern?

I think this is totally fine. Nothing to worry about. :) -- 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

Re: [elm-discuss] Elm, Objects and Components

entifiers would fix that as > well. > > P.P.S. This same work could also conceivably enable some form of DOM node > recycling. I think I recall that being part of the set of tricks that > Google Maps used to wow people on performance when it first launched and > it's part of what

Re: [elm-discuss] Elm, Objects and Components

I'm not sure what you mean there - what part about the status quo regarding form elements doesn't seem sensible? On Thu, Sep 22, 2016, 8:43 PM Max Goldstein wrote: > I really like Mark's summary, and I think Richard is incorrect to dismiss > the first point: > > 1. Make

Re: [elm-discuss] Elm, Objects and Components

some more tomorrow. > > Thanks Richard! > > > > On Tue, Sep 20, 2016 at 7:24 PM, Richard Feldman < > richard.t.feld...@gmail.com> wrote: > >> If nothing is wrong with Web Components, why not use them? >>>>>> >>>>> >>>&g

Re: [elm-discuss] Elm, Objects and Components

Yeah, I think this is a great thing for people to be playing around with. :) Underexplored territory! On Tue, Sep 20, 2016, 2:16 PM James Wilson wrote: > I haze thought about using web components like this too. You could even go > a step further and have web components that

[elm-discuss] Re: Post mortem for my first attempt at using Elm in a real app.

Thank you for posting this Peter! It's always informative to hear different perspectives. Sorry to hear yours wasn't positive. > -* I would not recommend webdev beginners to take the approach I took.* > This is my big takeaway here. At work we've had a great experience following the the

Re: [elm-discuss] Elm, Objects and Components

> > If these components are implemented in C++ and wrapped by the virtual-dom, >> we are lucky, we can use them. If they are not, we are out of luck. >> > Or you can define a Web Component like and then call node "myRadioButton"

[elm-discuss] Re: Proposal for a 1st-class, officially-supported CSS package

> > >1. Why not make Elm-CSS an officially-supported core package? > > Besides the fact that that's not up to me, I'd say the main reason would be that it's not officially supported. ;) It's just me and other community members working on it; there's no "official" support work being

Re: [elm-discuss] Proposal for a 1st-class, officially-supported CSS package

I agree with Noah. The class of errors language-level CSS value support would improve is so small, I can't think of a time its existence would have saved me a noticeable amount of debugging time. I value language simplicity, so by default any new language feature has a very high bar to clear to

[elm-discuss] Re: Sequence equivalent for Result type

If you click the "Fancy Search" link at the top of the right sidebar on http://package.elm-lang.org/ you can search by type signature! -- 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

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

> > On Sun, Aug 28, 2016 at 11:23 AM, Rex van der Spuy <dandylio...@gmail.com> > wrote: > >> >> >> On Sunday, August 28, 2016 at 4:14:43 AM UTC-4, Richard Feldman wrote: >>> >>> >>>> I gather that this is has to do with an interact

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

> > Components should only update their own private non-shared state that > other components don't need. Shared states such as your server queue are > updated at the highest level and each sub component merely receives a > function to run the update. > Apologies, but I have read and re-read

Re: [elm-discuss] A more concrete question about API design

Totally agree with Nick's advice . Well said! :) -- 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

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

> > I know you just like to let stuff accumulate in one monolithic piece, but > if you wanted to subdivide some of the major sections into sub-modules Just to be clear, at work we split things up into *modules* at the drop of a hat. If a particular file is too long, pulling some of it out

Re: [elm-discuss] Re: A more concrete question about API design

> > you seem insistent that the right approach to Elm is to write relatively > monolithic pieces of code and then try to tease them apart if they become > too complex. > Yes, exactly! Considering this is the most consistently successful approach to scaling in the entire history of software,

[elm-discuss] Re: A more concrete question about API design

> > I'm going to try to take the large app design questions and focus them on > a more narrow and *admittedly contrived example*. > > From what I understand of effect managers, we could write an effect > manager to do this but *the documentation around effect managers > discourages reaching

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

> > some scaling issues arrive the moment you would like to have two people > work on something. At that point, they can generally both be more > productive if you can subdivide the work, put an API in place in between, > and then let each proceed in a separate file. > I understand this

Re: [elm-discuss] Re: Composability without extensible records

Thanks! So let's start by talking about Slider for a sec. SliderMsg (Slider.ChangeValue newSpeed) -> { model | profile = newInternal, shared = Trip.setAverageSpeed model .shared newSpeed } Because this code compiles, and it only covers the ChangeValue constructor, then assuming

Re: [elm-discuss] Re: Composability without extensible records

Awesome! Best of luck with it! <3 On Wed, Aug 24, 2016 at 1:43 PM Charles-Edouard Cady < charlesedouardc...@gmail.com> wrote: > Thanks a lot, Richard, it makes much more sense now! > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Elm Discuss"

[elm-discuss] Re: Composability without extensible records

typo: should have written "i.e.its return type needs to be Html msg instead of Html Msg" -- 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] Re: Composability without extensible records

> > While I understand that not breaking things up too often is sound advice > in elm, I still think this doesn't answer my question Here is concretely what I'd do: type alias Model = { routes : List Route , hovered : Maybe Int , selected : Maybe Int , map : Map.InternalModel ,

Re: [elm-discuss] Re: Composability without extensible records

6 at 3:30:46 PM UTC-6, Richard Feldman wrote: >> >> >> >> On Tuesday, August 23, 2016 at 11:43:49 AM UTC-7, OvermindDL1 wrote: >>> >>> On Tuesday, August 23, 2016 at 11:24:22 AM UTC-6, Richard Feldman wrote: >>>> >>>> You are on the road

[elm-discuss] Re: Composability without extensible records

On Tuesday, August 23, 2016 at 11:43:49 AM UTC-7, OvermindDL1 wrote: > > On Tuesday, August 23, 2016 at 11:24:22 AM UTC-6, Richard Feldman wrote: >> >> You are on the road to #2, so my macro-level suggestion would be to go >> back to #1. :) >> > > #1 also

[elm-discuss] Re: Composability without extensible records

> I'm building an application to help ship captains create routes. My > question is about the organization of the model of this application. > > The application *currently has one page* containing *three widgets* > Sorry to ramble on about this, but it's been a thorn in my side for a long >

[elm-discuss] Re: Basic behavioral composition

> > `elm-mdl` is doing it that way because it is trying to follow how Google's > material library works, and since there is no way to introspect into the > virtualnode's to change how they act then it has to wrap things up in that > pattern, I.E., VirtualNode limitations and Html.Attributes

[elm-discuss] Re: Basic behavioral composition

This is a great question! I think there's a very clear answer here: *Don't overengineer it.* As you noted, this is basic - *super* basic - so by default, the best solution is also super basic. There's a button with 2 configurable options? Cool, let's write a function that accepts that

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

> > I have similar concerns about how deep down the stack Elm can go. At some > point, it seems like a good thing to separate business logic concerns from > UX logic concerns. This can already be done today, using plain old modules and organizing your data structures in a way that makes

[elm-discuss] Re: We need a clearer story on architecture

If you mean dividing a component into 3 separate files - ie. model.elm, > update.elm, view.elm , then yeah, that's fine. A single file is too. If you > have a massive Elm component that you feel is difficult to manage in a > single file, and splitting it into three pieces will make it much

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

> > Are you suggesting that each self-contained Elm "app" ("page", "game" > etc.) should only have one Model/View/Update and avoid using nested modules > for sub-components? Yeah - do you mean that something like the nested counter example from the Elm > Archtecture guide is a bad idea?

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

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

> > Haha yeah I get your point, but when you talk about the large redink code > base (no doubt it's huge), I'm curious of the granularity of your > production Elm apps. Is your code base generally organized as one/a few > large single page applications (routing handled client side - data via

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

> > But passing the callback down through the chain of nested components is > ugly, fragile and may not even work if two components are not in the same > parent-children chain. > Not quite sure if that's what this is saying, but a good rule of thumb is that Msg should never have a function

[elm-discuss] Re: Elm Generated Files are Quite Large

Yep! Preliminary work for dead code elimination has been done for awhile , but finishing it has never been justifiable as the next priority. I honestly doubt it'll be worth prioritizing in the next few months either...the

[elm-discuss] Easy first contribution: reproducing a record error message

If anyone is looking for a first Elm contribution, a SSCCE for this issue is pretty low-hanging fruit! :)

[elm-discuss] Should [ 1..5 ] exist?

Currently the way you do ranges (like, say, to create the list [ 1, 2, 3, 4, 5 ]) is this: [ 1..5 ] This comes up super infrequently, and whenever it does, it's hard to Google for - when you want to know things like "can I use variables in there?" "is [1..5] going to give me 1,2,3,4,5 or

Re: [elm-discuss] Re: Draft blog post - "How to Use Elm at Work" - looking for feedback

> Regarding the user form, you said that what I asked is trivial in Elm. > Do you have some kind of sample code that you can share or, if you would > be so kind, could you post some sample repository that does that? > I would *LOVE* to be proven wrong about that. I would love to see some >

[elm-discuss] Re: Try out the 0.17.1 beta

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