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

[Richard Feldman]

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 almost certainly coincidental!

-- 
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: Would Enums make a good addition to Elm?

[Richard Feldman]

>
> 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, is the difficulty of implementation. 
> DEAC's seem like an advanced language feature that will take a while to get 
> into the language.
>

Oh yeah - worth noting that this implementation already exists for records. 
Ports do it. If you send a record out a port, or bring it in through a 
port, under the hood what's happening is an encoder (or decoder, 
respectively) gets generated automatically from the type.

Doing it for union types as well would largely be a matter of designing a 
nice serialization and deserialization format; the type information is just 
as easy to access as it is for records. 

-- 
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: Would Enums make a good addition to Elm?

[Richard Feldman]

>
> 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 like the design work is what's 
hard. The implementation is actually not a ton of work, apparently.

That said, the design work *is* hard. 

Does a union type require that all fields/members are comparable as well?
>

I think that'd necessarily be true, yeah. But if union types and records 
are comparable (assuming they hold only comparable types), I *think* you 
end up with something like "functions aren't comparable, nor are 
Kernel-implemented values such as Value, Task, Cmd, and Html, but 
everything else is."
 

> As a reader, how easy is it to tell if a union type is comparable
>

Probably not easy, would be my guess. It's unclear to me how big of a deal 
that would be though.
 

> and is it obvious when one is lesser than another?
>

Apparently the way Haskell does this is by using the order of the tags 
(e.g. for type Maybe a = Just a | Nothing, we could say that Just "foo" > 
Nothing because Just came before Nothing in the type declaration), which 
seems fine to use since that ordering is currently arbitrary and 
meaningless. Similarly, record fields could be compared alphabetically by 
field name (since record fields definitionally have no ordering; if you 
needed them to be compared in a certain order, you could use a union type).

Considering the main (only?) reason people want them to be comparable is so 
they can be used in Sets and Dict keys, it doesn't seem hugely important 
how they compare, so long as they can be for purposes of internal data 
structure implementation details. I could be missing something though!

It's not straight forward from a design perspective.
>

I totally agree! 

-- 
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: Would Enums make a good addition to Elm?

[Richard Feldman]

>
> 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 keys in Sets 
> or Dicts.
>

Worth noting that (1) could also be fixed by having a deriving-esque way to 
generate encoders and decoders automatically, so long as it worked for 
union types as well as records. (Granted, the serialized format is less 
obvious with union types compared to records.)

Also worth noting that (2) is already slated to be fixed directly. It's a 
lower priority than other things in the hopper right now, but it'd probably 
still be higher priority than adding an enum feature. 

-- 
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] Would Enums make a good addition to Elm?

[Richard Feldman]

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 link to a longer 
explanation.

-- 
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: Tour of an open-source 4,000 LoC Elm SPA

[Richard Feldman]

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 build it
> - give it your likes folks.
>
> About web-pack - even though we're using it with elm in company project I
> never used it for any of my hobby project so far. Simply it makes sense to
> build from ground up not other way around. Also I think it's reasonable to
> stay focused so when the goal is to show Elm code then there's no need for
> unnecessary noise (webpack & env config). That's being said it still might
> make sense to create demo on "building webpack environment for Elm" which
> than can use rather simple Elm app and demo just setup of more complex
> environment (dev/test/prod) with SCSS for instance. That would be great too.
>
> --
> 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/hqO3P6uJiew/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: Tour of an open-source 4,000 LoC Elm SPA

[Richard Feldman]

>
> 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 Webpack, I 
gravitate towards not using Webpack. It hasn't exactly been the most 
delightful piece of software I've ever used. ;)

The main advantage to using the loader would be to show a way to integrate 
> Elm with the rest of the web tech especially SCSS and to provide a 
> development/deployment build environment.  


I suppose, but that wasn't my goal here. I understand your point, but I'd 
rather keep it decoupled from JS build tools...everybody's existing setup 
is going to be a bit different, and I would rather not give people the 
impression that they need anything special to build this application. :)

-- 
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] Tour of an open-source 4,000 LoC Elm SPA

[Richard Feldman]

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 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: Poll for Intermediate to Advanced topics that people struggle with

[Richard Feldman]

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 general (elm, javascript, other), or is there 
> an issue implementing authentication specifically in Elm? 
>
> On Tuesday, May 2, 2017 at 10:10:03 AM UTC-4, Alan McCann wrote:
>>
>> I echo Peter Damoc's entry + authentication (e.g. JWT)
>>
>> On Monday, April 24, 2017 at 10:06:53 AM UTC-4, Jeff Schomay wrote:
>>>
>>> Hello,
>>>
>>> I am considering doing some training material on working with Elm in 
>>> production.  I want to focus on areas that people struggle with after they 
>>> are already familiar with Elm.  What concepts continue to confuse you? 
>>>  What product requirements have been difficult to achieve with Elm?  What 
>>> is most painful about your Elm codebase?
>>>
>>> Some topics I have already thought of:
>>>
>>> - decoders
>>> - debouncing (http autocomplete input field for example)
>>> - scroll to element
>>> - testing
>>> - unwieldy update functions
>>> - api design
>>>
>>> If you have anything you'd like me to consider, please add it to the 
>>> list.  Thank you!
>>>
>>

-- 
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: Error Messages can they be made more intuitive?

[Richard Feldman]

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 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: Comments on the TEA Components package

[Richard Feldman]

>
> 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 without stating that 
> explicitly, devs are left to fill in the blanks themselves.


Gah, I wonder if that's what happened in Oliver's case. 

Let me try to clarify:

   1. Nesting Model-View-Update is a useful technique under the right 
   circumstances. One example is reusing complex things like signup forms. 
    
Another 
   example is a network of independent mini-apps like what Oliver is building. 
   And yes, absolutely, a third example - most likely the most common example 
   in use today - is going from the top level of a SPA to a logical "page" 
   within that SPA.
   
   In practice, pages almost always want their own model, view, and update, 
   and this technique is absolutely the right choice for having the top-level 
   application delegate to one of these "pages" depending on the current 
   route. (Note that this is true in Elm 0.18, but there may be an easier way 
   in 0.19 once asset management opens some new doors. However, even if that 
   happens, this will still be a useful technique to know about and use under 
   the right circumstances!)
   2. My objection is specifically to what I read in the OP, which suggests 
   that this situationally useful technique ought to be used pervasively:
   
   *In Elm 0.16, TEA was all about being composable. The examples focused 
   on things like going from one counter to multiple counters. [...] But 
   somewhere along the way, portions of the Elm community, including Evan, 
   seem to have swung hard against composing TEA units and now just recommend 
   using functions*
   
   Composing together Model/view/update triplets to build your application 
   has never been what the Elm Architecture was "all about."
   
   The reason *"The examples focused on things like going from one counter 
   to multiple counters"* is no longer true is that Evan took those 
   examples down once he realized they'd been giving people this wrong 
   impression. He'd intended to convey "check it out - here is a useful tool 
   to include in your toolbox" but a lot of readers (quite reasonably) read it 
   as "this is the right technique to use whenever I want to build something 
   reusable, even something as simple as a counter" - which was never a 
   message Evan intended to send.
   
   To be super clear, even though I think this technique is useful in the 
   right circumstances, I disagree with the notion that "composing TEA units" 
   is what the Elm Architecture is "all about," and I again disagree that the 
   right way to think about organizing the content of "pages" within an 
   application is in terms of composing model/view/update triplets. It really 
   is all about the individual functions!
   
I hope this clarifies...I totally appreciate that my attempts to share what 
I've learned over these past few years do not always come across as I 
intended, and I am extremely grateful for the direct and honest feedback. :)

>

-- 
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: Comments on the TEA Components package

[Richard Feldman]

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

That is a fantastic idea and I totally want to do that now!

-- 
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: Comments on the TEA Components package

[Richard Feldman]

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 mini-app is also  included in a view more 
> closely resembling Slack with a sidenav etc...Each mini-app is then 
> responsible for it's own lifecycle (e.g. Loading/Loaded/Error).


I apologize for giving you advice that led to a design that didn't work 
well for the mini-app business requirements, but I'm really glad to hear 
you were able to refactor it into a happy place! I can also appreciate that 
you liked how this worked in broader contexts. :)

That said, based on your note of *"reusable view modules, may include any 
combination of view/update/Model but few have their own update/Model" - *it 
sounds like we are approximately on the same page with regards to reuse. ;)

-- 
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: Comments on the TEA Components package

[Richard Feldman]

>
> 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 and 
> are far happier since (the change was made at the start of the year).
>

Fair enough!

*Reusable view components* 
> We view these as distinct from the mini-apps that I mentioned earlier.  


Ahh, right, this "mini-apps" design sounds familiar to me. I think I 
remember talking to you about this awhile back - as I recall, you had some 
really interesting business requirements in terms of how and when parts of 
the page were loaded.

If you have time, would you mind describing how the app works?

-- 
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: Comments on the TEA Components package

[Richard Feldman]

>
> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Richard Feldman]

>
> 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 telling 
them Decades Of Experience Dictates Can't Possibly Work and found that it 
actually worked great when they tried it.

The old "who are you gonna believe, me or your lying eyes?" argument does 
not have a great track record.
 

> To the extent that we live in a world where we all say "you're free to 
> develop software however you see fit", we can often take the attitude. 
> "That's interesting. It wouldn't work for me but I see why you are making 
> those choices."
>

It seems that from your perspective, this is an intellectual exercise with 
low stakes. I see this as a discussion that has great potential to cause 
pain, because I've seen a lot of pain result from past discussions on this 
topic.

A lot of people follow what you're advocating and then end up reporting 
that they had a really bad experience with it. I ask where they got the 
idea that this would be a good approach to follow, and they point to a blog 
post someone wrote, or a discussion thread where nobody stood up for the 
simpler alternative. Then I point them to advice like this 
,
 
and I get a lot of people coming back to thank me afterwards, saying they 
got out of the "component mindset" and now they're happy with how their 
code scales.

*I have not seen the reverse happening.* I don't see people saying "I 
decided to refactor everything to be based around model/view/update 
triplets just because, and I was much happier with my code afterwards." 
Obviously it's not impossible to follow your advice and have a fine time 
anyway, but I can confirm at least one case - myself - where someone 
consciously shifted towards the "component mindset" (before it had that 
name) and hated working with the result so much, he halted work on the 
project until he could refactor it back to the old way.

You keep acting like this is unexplored territory even though *it has been 
explored by many people.*

I'm not going to pretend discussing things in a public form has no 
consequences for beginners who come across it later. Call me a 
bold-text-using verbal ruffian if you like. If I can pull people away from 
a cliff, I intend to. :)

-- 
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: Comments on the TEA Components package

[Richard Feldman]

>
>
> 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. Looks like I still miss 
> something. Are you trying to say that Cmd.map is not function or what?
>
 
What I'm saying is that *individual functions*, as opposed to *a group of 
functions and data structures* (model, view, update, msg, etc) is the right 
unit of composition.

In the example earlier in this thread 
, I 
showed an API for a reusable checkbox using a single function. I then 
showed an alternate API that resulted from the mindset that a *group* *of 
functions and data structures* (model, view, update, msg, etc) should be 
the atomic *unit of composition* - the notion that "you should build Elm 
applications by composing together model/view/update triplets" which I've 
seen cause pain. I pointed out that this mindset led to an overengineered 
checkbox API that was unnecessarily complex.

Does that clarify?

on different topic:
>
>  many of us have tried this, and found that composing individual functions 
>> was both simpler and consistently led to a much better experience.
>
>
> Not even pointing out all nonsense: I just don't see any of them here 
>  just 
> yet. I hope they will shop up.
>

I'm not going to dig up a bunch of peoples' names and pester them to 
testify that this actually happens. :P

Please don't start sending links to same Reddit thread once again.


I'm doing that so that if beginners stumble on this thread and skim through 
it, they don't have to dig for what I'm recommending. :)

-- 
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: Comments on the TEA Components package

[Richard Feldman]

 

> 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, you're not alone in seeing something not OK 
> with that. 
>

It's responsible to call out alluring antipatterns that consistently lead 
people to pain.

I'm sorry if you dislike that, but it's important. :)

Other than the update trick, it's more or less the same thing as the old 
> MUV triplets. 
> You can even use the pattern to do nesting.
>

"You literally can do this and it will compile" is not much of a pitch for 
a more complex alternative to the simpler approach that already works well 
.
 
;)

>

-- 
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: Comments on the TEA Components package

[Richard Feldman]

>
> 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" sounds like 
> "no reusable UI". But isn't sortable-table a component? For those who 
> understand the context, it is not a component, but I don't know how others 
> feel (especially who come from JS world).
>

I can see that, but given that the problem is "this word means many 
different things to many different people," the only way to have useful 
discussion seems to be insisting on using less vague terminology. I 
recognize the problem that people are used to using this word [to mean 
different things], but I don't see a better solution.

Can you think of a way to use this overloaded word in a way where the 
people in the discussion are not confused by it, even though they think it 
means different things?

Also, "no components, no nesting TEA" does not answer the problem discussed 
> here. So how can we do instead?
>

I covered how to grow Elm application code bases 
,
 
and Evan covered reuse .

What is the remaining problem? :)

-- 
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: Comments on the TEA Components package

[Richard Feldman]

>
> 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). Without 
> nested TEA, how can we use this library? [...] elm-sortable-table is a good 
> example (I wonder why nobody mention it, btw). Calling update function is 
> not needed. You can use it just like  element. I hope UI libraries 
> that uses this pattern will increase.
>

I think Sortable Table is a perfect example of this!

How do we use the library? The same way we use any library: we read the 
docs and plug into the API it provides.

It doesn't need to be any more complicated than that. :)

Terms like "component is proven to be an anti-pattern" sounds too negative 
> for me.
>

I appreciate the sentiment, but I think it's appropriate to be negative 
when exploring something has yielded an overall negative result. :)
 

> It sounds like "Elm proposes DIY every time, no reusable UI ever!", even 
> if you mean "no need to make everything a component for building app, there 
> are actually not so many reusable UI parts in practice".
>

I'm curious what makes it sound that way, since as you noted, that is not 
the point I'm making.

Any feedback on how I could be clearer would be appreciated!

>

-- 
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: Comments on the TEA Components package

[Richard Feldman]

>
> 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" which as I've 
> noted doesn't mean much in a functional language.
>

It means YAGNI . Don't 
overengineer it. :)

As for C++ example I cited, there is nothing Elm is bringing to the table 
> that makes it superior to C++ in the case I described. C++ is fully 
> type-checked.
>

In Elm, if I refactor something, my typical experience is "once it 
compiles, it works." It's been a long time since I did C++, but my memory 
of that experience was a far cry from that.

It sounds like your C++ refactoring experience has been close to your Elm 
refactoring experience, which surprises me.

-- 
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: Comments on the TEA Components package

[Richard Feldman]

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

 somehow 
amounts to not splitting things up at all. Someone called you out on it 
, and 
then you switched insults from "ball of mud" to "monster model." If you 
genuinely want to have a discussion, it's important not to misrepresent the 
other side.

It's also weird to me that you keep responding to my point of "this 
approach has worked really well for lots of Elm programmers, in practice, 
in real life, already" with "I bet that won't work well in practice, in 
real life, based on my experiences in other languages." We're past the 
point of theoretical predictions here. The experiment has already been 
done, and then replicated successfully many times.

Your comment that "this approach didn't work for us in C++" seems 
particularly weird. I'd say there are "a few" differences between Elm and 
C++, refactoring experience included. ;)

-- 
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: Comments on the TEA Components package

[Richard Feldman]

>
> 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 posts ago, complete with 
>> the specific example of the reusable signup form.
>
>
To recap:

   1. Earlier 
    I 
   said "between 0.16 and today, *we learned that a Model-View-Update 
   triplet is the wrong unit of composition for Elm applications...composing 
   individual functions* was both simpler and consistently led to a much 
   better experience. I've laid out my advice for specifically how to do that 
   here 
   

   ."
   2. Later 
    I 
   pointed out an example of when it would be useful to use Html.map and 
   Cmd.map to make a reusable signup form, and for that use case it 
   happened to make sense to have a separate model, view, and update.

In (1) I am saying that I expect you'll have a better time if you think 
about building Elm applications in terms of *composing individual functions*, 
not in terms of composing Model/View/Update triplets.

In (2) I am giving an example of a very specific set of circumstances in 
which a separate Model/View/Update makes sense.

In summary: "Here is a useful but complex tool. Always reach for a simpler 
one first." 

>

-- 
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: Comments on the TEA Components package

[Richard Feldman]

> 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 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: Comments on the TEA Components package

[Richard Feldman]

My point that there's a simple way to scale Elm applications by abstracting
at the function level has gone uncontested for awhile in this thread. I
think at this point I've said my piece and might as well move on.

It's cool for people to have philosophical goals separate from the goal of
a nice 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:
>>
>> "Everything ought to have the same API" is a much harder claim to defend.
>> It sounds wrong at face value, and I haven't seen any evidence (in this
>> thread or elsewhere) to convince me that it's a wise goal to pursue. :)
>>
>
> But isn't the entirety of the html package and actual example of an
> unified API?
> All the widgets there have the same API: widget : List (Attribute msg) ->
> List (Html msg) -> Html msg
>
>
> checkbox : (Bool -> msg) -> Bool -> Html msg
>
>
>
> How about the case where one has calls to a server involved? for example a
> weather widget or some kind of "Quote of the day" widget, a stocks ticker,
> etc.
> How does one handles side-effects (http, random, time etc) with this
> pattern?
>
>
>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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/Lo6bG96zotI/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: Comments on the TEA Components package

[Richard Feldman]

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

Crucially, between 0.16 and today, *we learned that a Model-View-Update 
triplet is the wrong unit of composition for Elm applications.*

It's important that people understand the historical context here: many of 
us have tried this, and found that composing individual functions was both 
simpler and consistently led to a much better experience. I've laid out my 
advice for specifically how to do that here 

.

In any event, I recommend that those interested in ways to structure large 
> Elm programs go look at this. It doesn't radically change anything but it 
> could be a better way to express the composition of TEA-shaped units.
>

I'll reiterate that thinking about application organization as "composing 
TEA-shaped units" is neither officially recommended nor what Elm is 
designed for, and many folks have tried to fit that round peg into the 
square hole and reported that it led to pain at scale. Specifically I've 
had many people tell me that refactoring according to this advice 

 led 
to a much better experience.

Exploring can be fun, but if you're looking for a good way to organize your 
Elm applications, be aware that this particular path has been explored 
before - and there's a signpost next to it labeled "WARNING: PIT OF SNAKES 
AHEAD." ;)

-- 
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: Post Examples of Painful Record Updates Here!

[Richard Feldman]

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 useful than hypothetical examples that use foo! :)

-- 
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: Post Examples of Painful Record Updates Here!

[Richard Feldman]

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
> record, there is no syntax to further pattern match on it. Again, abusing
> the 'as' syntax in a quite different way to how it is currently used,
> something along these lines:
>
> func { field } =
>   let
>  SomeConstructor arg = field
>   in
>  arg
>
> Could be shortened to:
>
> func { field as SomeConstructor arg } = arg
>
> Sorry, that wasn't an update but it relates to record syntax.
>
> --
> 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/oWfARte8DJU/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: Post Examples of Painful Record Updates Here!

[Richard Feldman]

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 verbose and the other 
relying on exposing values that would read better if fully qualified 
instead of exposed:

import Slides

slidesDefaultConfig =
  Slides.defaultConfig

myCustomSlidesConfig =
 { slidesDefaultConfig | someAttribute = myCustomvalue }

or

import Slides exposing (slidesDefaultConfig)

myCustomSlidesConfig =
 { slidesDefaultConfig | someAttribute = myCustomvalue }

Not a big deal TBH, but annoying.


-- 
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] Post Examples of Painful Record Updates Here!

[Richard Feldman]

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 
step in the process is to gather those examples.

So let's collect a ton of different real-world examples! That will help 
guide the design process.

If you've run into a record update that you felt was painful and could be 
improved in some way, please post it here! (Also, *please keep this thread 
for posting of examples* *only* - it'll be easier to link back here during 
design discussions if we can reference a clean thread of examples, as 
opposed to a mismash of examples interleaved with suggestions.)

-- 
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: Emphasizing /r/elm more

[Richard Feldman]

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 
frustrating mix of misinformation and wild speculation. I don't see a way 
to avoid beginners clicking through and being misinformed by what's being 
said there, other than responding myself, which further contributes to its 
being bumped to the top of the list.

That thread has singlehandedly convinced me we should move away from 
elm-discuss. Actively rewarding the lowest-quality discussions is really 
bad. :(

-- 
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: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[Richard Feldman]

>
> 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 the 
> reason.  The problem isn't so much the use of Array's versus 
> objects/records, but the string tags, which as the Elm JS output doesn't 
> preserve type information except by these tags, are continuously requiring 
> string processing to determine the type of object at run time.  Elimination 
> of these strings by using the type information the compiler already has 
> would greatly speed things even if objects are used, with the further 
> advantage of Arrays being that their indices are numeric for slightly less 
> processing (depending on the browser engine used).
>

Modern JS engines intern string literals 
,
 
making them in general faster than index-based Array access. I would 
definitely expect this idea to result in a performance regression for Elm, 
and I would be very surprised to see benchmarks to the contrary.
 

> My point is that for those of us that need speed - at least a few that 
> have chimed in on this thread - if it isn't addressed with the Elm compiler 
> then Elm might migrate to a front end to OCaml which would schism 
> development efforts and possibly hurt the language.
>
My other point is that the sooner it is done the easier it will be.
>
And it doesn't affect those that find current Elm speed adequate - all that 
> is needed is enough contributors and co-ordination between the different 
> developments.
>

I don't think any of this has even the remotest chance of happening.

You seem very earnest, though, so I suppose we'll have to agree to disagree.

-- 
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] Is Elm.worker gone in 0.17?

[Richard Feldman]

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 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: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[Richard Feldman]

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


Considering Evan is working on asset management for the next release, I 
doubt "compile everything to one file" will be true after it lands. (That 
release is presumably still several months away; this is just speculation 
on my part.)

Evan also wrote C++ at Google, so avoiding long linking times is definitely 
on his radar. ;)

-- 
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: [Suggestion] Type values and simplifying the language still

[Richard Feldman]

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 serialization and deserialization. The compiler could 
generate a lookup table to determine not only how many arguments should be 
passed to the constructor (solving the problem mentioned in OP) but also 
their types.


Everything else is similar to the field schema used by Native modules, 
except with $ instead of _. I understand that browsers do undesirable 
things to object keys that can be parsed as integers, so it's important 
that the indices be prefixed with some non-numeric character like _ or $.


I think $ is a more human-friendly prefix than _, because it appears in the 
wild: $ followed by an index refers to regular expression capture groups in 
languages including JS, Perl, and Ruby, e.g.


"Sam Sample".replace(/(\w+)\s(\w+)/, "$2, $1" === "Sample, Sam"`


An alternative (which I like less) was proposed elsewhere 
 and 
looks like this:


{"tag": "Maybe.Just", "contents": [5]}


The idea being that if the union type holds multiple values, we just stick 
them in the heterogeneous contents array. This might look less weird to 
someone comfortable with JS, but using it would be worse. It would 
encourage iteration when iteration makes no sense, and it would have worse 
lookup performance than object fields would.

-- 
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: [Suggestion] Type values and simplifying the language still

[Richard Feldman]

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
   - The consensus is that curried is nicer than tupled for Elm functions 
   on the whole
   - Why would the opposite be true for these particular functions?

I don't have a good answer for that, which makes me lean toward the status 
quo.

That said, automatic serialization/deserialization of union types would be 
nice. :)

-- 
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: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[Richard Feldman]

>
> 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 
>> 
>>  
>> of the new version if you're curious. :)
>>
>
> I saw that over on elm-dev, but haven't tried it because compilation speed 
> isn't a problem for the Elm code I have written so far.  The only reason I 
> brought it up is OvermindDL1's comment 
>  that 
> compiling a Ocaml/BucketScript code (that presumably did the same thing as 
> the Elm code) took about 0.1 seconds as compared to 40 seconds with the Elm 
> compiler - a 400 times speed-up!  We weren't given details of the code or 
> test conditions and whether one was an incremental compilation, but that 
> sounds quite serious and would affect the usability of Elm.  If that data 
> is verifiable, a speed up of double or even quadruple doesn't begin to 
> touch the difference and should be investigated.
>

If only there were a binary posted somewhere, based on a compiler that had 
just been rewritten to improve build times, so that someone could post a 
benchmark instead of speculation! ;)

-- 
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: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[Richard Feldman]

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

 
of the new version if you're curious. :)

-- 
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: Intended usage of -- comments (and elm-format)

[Richard Feldman]

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

-- 
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: UI effects (align/tether, scroll into view) after elements are inserted

[Richard Feldman]

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 = document.body.querySelector(
selector)) in a call to requestAnimationFrame.

See if that works!

-- 
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: Emphasizing /r/elm more

[Richard Feldman]

>
> 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 going to see use 
regardless, so any alternative introduced has the minimum downside of 
fragmenting where discussions happen.

I don't think that makes /r/elm the automatic best choice, but I do think 
it makes it worth a shot.

I'm planning to spend more time there.

-- 
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: Feature: 'where' expressions (continued from GitHub)

[Richard Feldman]

>
> 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 wise to refuse.
 

> Is he the kind of person who is adverse to criticism in general?


Far from it.

I've never met him personally, but I'm sure he's very well-intentioned.


For sure! As is everyone in this thread. :)
 

> That said, conflict breeds evolution and improvement.

 
It also slows down projects. If Evan spent time seriously considering every 
possible syntax improvement, Elm still wouldn't even have a virtual DOM 
system.

Elm needs people to tell it that it isn't good enough, and that's what I 
> and the flood of past and future people wanting `where` in Elm are saying.


There haven't been a "flood" of people asking for this feature. There has 
been a flood of *discussion* from an extremely small number of people. This 
is *not* a pain point for the overwhelming majority of the Elm community, 
and insisting otherwise primarily serves to suggest one may be overselling 
one's knowledge of said community.

Historically, Evan has been amenable to syntax changes such as the 
following:

   - Changing a legacy syntax decision inherited from Haskell to something 
   more user-friendly. (Examples: type alias, import Foo exposing (..), 
   changing module Foo where to module Foo exposing (..))
   - Deleting syntax from the language. (Examples: backticks, primes, 
   ranges)
   - Additions in the service of a major new feature. (Examples: port, 
   and...yeah, this language has existed for almost 5 years I can't come up 
   with any others. I think that paints a pretty fair picture of where the bar 
   is for new syntax to make it into the language.)

I've heard Evan say "I'm not making this language to fight the syntax 
wars," and I think that's a sensible way to prioritize a language as 
ambitious as Elm. (Ambitions like someday making it the best server-side 
language too.) There are an unlimited number of ways Elm's syntax could 
potentially be improved incrementally. Considering things takes time, and 
if Evan spent time even considering every proposed incremental syntax 
improvement, no progress would ever be made on the rest of the language.

At some point there has to be a bar for "this is not worth the time it 
would take to seriously consider it." A syntax feature that would, at best, 
be an incremental improvement over a status quo that only a tiny fraction 
of the Elm community finds objectionable...to be honest, I'd consider it 
pretty irresponsible of Evan as a language maintainer to spend time 
seriously considering whether this would be a good change to make - let 
alone implementing it.

Carry on debating if you like, but please be aware your odds seem 
vanishingly low to outside observers who have been around for at least 3 
years each.

*PS:* I am usually in the habit of responding to rebuttals, but in the case 
of this thread I do not intend to post again. I've said my piece. If you 
find my reasoning objectionable or fallacious, fine: skewer it. It's your 
time. Spend it however you find most meaningful.

-- 
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: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[Richard Feldman]

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 https://groups.google.com/d/optout.

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

[Richard Feldman]

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 
similarities/differences to this one.

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

[Richard Feldman]

No new thinking on that as far as I'm aware...what are you looking to build?

On Mon, Dec 5, 2016, 8:37 AM Wil C <iam...@gmail.com> wrote:

> Do you know if there's going to be a guide on native modules? I just used
> elm-markdown as a guide, but I saw there were other conventions 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, Richard Feldman wrote:
>
> Looking at the evancz/elm-markdown
> <https://github.com/evancz/elm-markdown> parser, that seems like a case
> that warrants it, yeah.
>
> --
> 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/nuR4NnCVcMs/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: Stance on native APIs for 0.18?

[Richard Feldman]

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, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Richard Feldman]

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 run into this before. It can be caused by runaway recursion. Can 
> you share your Elm code with us?
>
> On Dec 2, 2016, at 8:42 AM, Iain Gray  
> wrote:
>
> I'm having a strange problem and was wondering if anyone had any 
> suggestions on how to pinpoint what is causing it.
>
> I have an Elm app that compiles in 0.18, but the generated javascript code 
> is throwing a "RangeError: Maximum call stack size exceeded" as soon as the 
> javascript file is loaded into Chrome. I do not have this problem in 
> Firefox, but I can reproduce it in nodejs/esprima as follows:
>
> var esprima = require('esprima');
> var fs = require('fs');
> var filePath = path.join('.', 'elm.js');
>
> fs.readFile(filePath, 'utf8', function(err, data) {
>   console.log(esprima.parse(data));
> });
>
> RangeError: Maximum call stack size exceeded
> at isKeyword (.../node_modules/esprima/esprima.js:359:23)
> at scanIdentifier (.../node_modules/esprima/esprima.js:729:20)
> at advance (.../node_modules/esprima/esprima.js:1573:21)
> at lex (.../node_modules/esprima/esprima.js:1691:78)
> at expect (.../node_modules/esprima/esprima.js:2521:21)
> at parseObjectInitializer (.../node_modules/esprima/esprima.js:3047:9)
> at inheritCoverGrammar (.../node_modules/esprima/esprima.js:2681:18)
> at parsePrimaryExpression (.../node_modules/esprima/esprima.js:3247:20
> )
> at inheritCoverGrammar (.../node_modules/esprima/esprima.js:2681:18)
> at parseLeftHandSideExpressionAllowCall (.../node_modules/esprima/
> esprima.js:3414:20)
>
> If I start node with --stack-size=1200, I no longer get the error and 
> esprima can successfully parse the code. Unfortunately, I can't seem to do 
> this with Chrome. I tried:
>
>   
> Error.stackTraceLimit = 1200;
> var js = document.createElement("script");
> js.type = "text/javascript";
> js.src = './elm.js';
> document.body.appendChild(js);
>   
>
> ... which doesn't seem to change anything.
>
> I've been commenting out different sections of my code in an attempt to 
> see what part is ultimately causing this, but that has been pretty painful. 
> If anyone has any suggestions, I'd love some advice.
>
> Thanks,
> Iain
>
> -- 
> 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.

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

[Richard Feldman]

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 google-maps / polymer version but had 
> trouble getting google-map-marker 
> s to work as 
> children of the map element. Did map markers work for you?
>
>>

-- 
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] Inter triplets communication.

[Richard Feldman]

>
> 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 way you could modify the earlier example to do this:

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
case msg of
UserInfoMsg subMsg ->
let
( userInfoState, subCmd, user ) =
UserInfo.update model.user subMsg model.userInfoState

fetchRatingsCmd =
if model.user == Nothing && user /= Nothing then
-- user was previously Nothing, but now isn't; we 
just logged in.
-- that means we should fetch new ratings from 
storage!

fetchRatingsCmdGoesHere
else
Cmd.none
in
( { model | userInfoState = userInfoState, user = user }
, Cmd.batch [ fetchRatingsCmd, Cmd.map UserInfoMsg subCmd ]
)

Even more, it is exactly like described here 
> https://gist.github.com/evancz/2b2ba366cae1887fe621 
> 
>  by 
> the author of Elm 
>
This is a gem. Not seen it before but there are some really useful ideas in 
> there. 
> It had not occurred to me that we can create record types with a 'hole' in 
> them, which can then be used to compose them together to build larger 
> records, but at the same time we can write functions that just operate on 
> whatever components of the record we choose as the level of abstraction to 
> re-use. I'm talking about the "Reusable Actions" section.


Yikes, definitely don't do that! That link is from Elm 0.13 - back when 
everything was based around Signals, the Elm Architecture did not exist 
yet, and Evan was still trying out different approaches to figure out what 
worked best.

That section is one of the experiments that *did not work out* in practice, 
and was rejected in favor of the approach he recommends today in the Guide. 
(There's a very good reason he didn't talk about this pattern in the Guide 
- and it's not that it was awesome but he somehow forgot about it!)

On of the interesting solutions https://github.com/folkertdev/outmessage  
> another http://package.elm-lang.org/packages/prozacchiwawa/effmodel/2.0.0/
> and elm-parts 


I never use these libraries. If installing one ever sounds appealing, I 
have almost certainly overcomplicated my state management and a better 
course of action would be to refactor. ;)

How would you do this differently?


I don't have strong feelings about module organization conventions in 
general. I basically feel like if I'm not happy with how my application's 
modules are organized, it's easy to reorganize them, so it's not something 
I spend a lot of time thinking about. I'm more concerned with which values 
a given module does or does not expose (especially in libraries) than file 
and folder structure. :)

Hope this helps!

-- 
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] Inter triplets communication.

[Richard Feldman]

>
> 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 
> details.
>
And it is differently similar to components and pretty abstracted and 
> reusable. 
>

In libraries that have component systems, components are used as a common 
building block. They're encouraged as a good default choice, a method of 
reuse to reach for as a matter of course.

When making something reusable in Elm, we always want to start with data if 
we can get away with it. If we can't get away with data, then we use a 
function. If a function still won't do the trick, we try upgrading it to a 
higher-order function. Only after all else fails do we resort to 
encapsulating a separate model, update, and view. It's the most expensive 
way to reuse anything, not something we should reach for as a matter of 
course!

That's the difference. Components are something you use at the drop of a 
hat. In Elm, encapsulated state is something you use when you tried all the 
simpler ways to reuse something first, and none of them worked out.

Hence my objection to *"I know that Elm doesn't have the concept of 
components but instead it has triplets."*

What I'd say instead is *"I know Elm doesn't have the concept of components 
but instead it discourages encapsulating state except as a last resort." *

Like Evan said, "it just works different in Elm. We do not think in terms 
of reusable components." :)

This "not component" will be used here only once (or more but not now) but 
> should be used in several similar projects.They all will be using the same 
> Identity Service so userInfo(and login/logout) should look and feel similar.
>

That greatly clarifies things, thank you!

Since this is going to be used in multiple projects, it will want to be a 
separate package. I would look at thebritician/elm-autocomplete 

 
as a starting point.

I'd give UserInfo its own model, view, and update (since it is clearly 
doing a bunch of complicated state logic, all of which needs to be 
reusable) and expose a UserInfo.update function like this:

update : Maybe User -> UserInfo.Msg -> UserInfo.State -> ( UserInfo.State, 
Cmd UserInfo.Msg, Maybe User )

The idea is that the caller is responsible for storing the logged-in (or 
not, hence the Maybe) user - we don't store that user inside UserInfo.State. 
If the user logs in, we inform the caller by passing Just loggedInUser as 
the third element in the tuple we return. If the user logged out, we return 
Nothing. If neither happened, we return untouched whatever user the caller 
passed us. Regardless, it's up to the caller to store that information.

So the caller's update might look something like this:

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
case msg of
UserInfoMsg subMsg ->
let
( userInfoState, subCmd, user ) =
UserInfo.update model.user subMsg model.userInfoState
in
( { model | userInfoState = userInfoState, user = user }
, Cmd.map UserInfoMsg subCmd
)

Similarly, this would mean UserInfo.view would take the user separately as 
well, which the caller would be responsible for passing in:

view : Maybe User -> UserInfo.State -> Html UserInfo.Msg

Hope that helps!

-- 
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] Unpublishing a package

[Richard Feldman]

>
> 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 0.19) is for packages to 
be downloaded from somewhere other than the source repo.

-- 
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] Unpublishing a package

[Richard Feldman]

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 the package is gone now (and perhaps what to use instead).

-- 
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: Interactive maps with Elm 0.17 : recommendation?

[Richard Feldman]

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 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: Integrating Elm with Web Components / Polymer

[Richard Feldman]

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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Inter-Component Communication in 0.17

[Richard Feldman]

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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Why aren't doc PRs merged?

[Richard Feldman]

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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Richard Feldman]

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 instead of ready did the trick.
>
> Thanks for taking the time to figure this out!
>
> Now, the next challenge is to figure a way to declare all this in Elm and
> automate as much as possible the process of creating the custom components.
> :)
>
>
>
>
> On Tue, Oct 11, 2016 at 12:31 AM, 'Rupert Smith' via Elm Discuss <
> elm-discuss@googlegroups.com> wrote:
>
> On Monday, October 10, 2016 at 3:38:13 PM UTC+1, Peter Damoc wrote:
>
> I have already tried doing this but have run into troubles:
>
> Here is the topic where I have the code and the problem:
> https://groups.google.com/forum/#!topic/elm-discuss/QI6G6Pd5jPU
>
>
> I think you just didn't get the lifecycle quite right:
>
> https://www.polymer-project.org/1.0/docs/devguide/registering-elements
>
> I moved the embedding of the elm component to the 'attached' method
> instead. It seems that attribute values are not set on the properties until
> attached, and only have the default values when 'ready' is called.
>
> Needs some tidying up (tomorrow), but what I have checked in seems to be
> working:
>
>
> https://github.com/rupertlssmith/elm-polymer/blob/master/counter-elm-webcomponent/elm-counter.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 more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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/8Q2xwRh6UYc/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: Is over-use of 'let... in' considered an anti-pattern?

[Richard Feldman]

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 options, visit https://groups.google.com/d/optout.

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

[Richard Feldman]

Mark, this seems worth a separate thread. Would you mind opening one that
explains a couple of motivating problem scenarios, and then this proposed
solution?

On Sat, Sep 24, 2016, 5:28 PM Mark Hamburg <mhamburg...@gmail.com> wrote:

> I wonder if the following strategy would work to address this...
>
> 1. Bring back some form of general purpose keyed identifier for virtual
> DOM nodes.
>
> 2. Before diffing two virtual DOM trees, build a map from keys to DOM
> nodes for such keyed nodes. When processing a reference to a node in the
> result, if it has a key, prefer to use the entry in this map. (Multiple
> uses of the same id need to have some logic to keep things from blowing up
> but we could reasonably lose the optimization for all but the "first" use
> of an id.)
>
> Challenges:
>
> * Will this actually work well with the real DOM or will removal and
> reinsertion cause problems?
>
> * This is essentially based on doing full scans of the tree and I assume
> there are optimizations around subtrees that haven't changed. Those
> subtrees would at least need to be scanned to continue their claim on DOM
> nodes with identifiers.
>
> But if this works, then the fix for a text node or web component getting
> its state whacked would be to give it an identifier.
>
> For lists, the new keyed support is great and probably more efficient than
> what we had before. But for creating "identity" for view nodes, it probably
> isn't what is needed and what was there before while better was not really
> fully sufficient either.
>
> Mark
>
> P.S. There is also a related problem for external components with not
> getting new components when we want them. Identifiers 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 Apple's UITableView does to get performance in native
> lists.
>
> > On Sep 24, 2016, at 8:27 AM, Richard Feldman <
> richard.t.feld...@gmail.com> wrote:
> >
> > Yep, very true. I would love for there to be a better solution for text
> fields in particular.
> >
> > --
> > 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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/2RTddO_4rLw/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.

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

[Richard Feldman]

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 sure the virtual DOM works "sensibly" with elements with hidden
> local state.
>
> Checkboxes, drop downs, and other form inputs are a root problem. Maybe
> the solution is web components, but maybe not.
>
> --
> 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/2RTddO_4rLw/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.

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

[Richard Feldman]

No problem! Hope it works well. :)

On Tue, Sep 20, 2016 at 2:22 PM Peter Damoc <pda...@gmail.com> wrote:

> Hmm... I tried integrating the icon-toggle-demo and, to my surprise, I got
> it working even if it's past midnight here and I'm dead tired.
>
> I need to explore this 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?
>>>>>>
>>>>>
>>>> There are a ton of them
>>>> <https://elements.polymer-project.org/browse?package=paper-elements>
>>>> you could use right now, for MDL in particular, that work right off the
>>>> shelf.
>>>>
>>>>
>>> You make it sound like it's a trivial thing for a beginner to integrate
>>> Polymer with Elm and hit the ground running.
>>>
>>> I seriously doubt that this is the case but I'll take another look at
>>> the projects that have attempted to do this. :)
>>>
>>
>>1. npm install Polymer
>>2. Add  to
>>your index.html
>>3. Add this before the script that imports your elm.js: 
>>// register an element
>>MyElement = Polymer({is: 'my-element',
>>created: function() { this.textContent = 'My element!'; }
>>});
>>
>>4. In your Elm code, run Html.node "my-element" [] []
>>
>> I just tried this and it worked. :)
>>
> --
>>
> 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.
>>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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/2RTddO_4rLw/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.

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

[Richard Feldman]

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 embed Elm inside themselves the
> same way you can whack Elm into any other element. So perhaps a collection
> of Elmish web components points one path forward!
>
> The other nice thing about embedding web components into Elm as easily as
> we can is that they can be used to wrap native JS things into El as well.
> For example one might make a web component to render a google map based on
> ita attributes, and in Elm we just Html.node "google-map" [] []. Definitely
> something I need to play with more!
>
> --
> 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/2RTddO_4rLw/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: Post mortem for my first attempt at using Elm in a real app.

[Richard Feldman]

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 philosophy Noah 
advocates here, of "when feeling blocked, reach for a workaround," but 
that's predicated on knowing how to do the workarounds. Based on your 
experience, I can see how a web development beginner would not have that 
toolbox already at hand.

I think it's fair to say that Elm is a great choice for projects where 
teams are already comfortable doing Web development, but I can see how it 
wouldn't be the best choice a beginner building one of their first 
production Web applications. I expect that will change over time, but we 
are not there yet. :)

>

-- 
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] Elm, Objects and Components

[Richard Feldman]

>
> 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" to create one. No C++ 
involved.

What's wrong with that?

-- 
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: Proposal for a 1st-class, officially-supported CSS package

[Richard Feldman]

>
>
>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 done on it.

>
>1. Is there a roadmap for Elm-CSS or suggested ways to improve it?
>
> Pretty much just the stuff on https://github.com/rtfeldman/elm-css/issues 

-- 
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] Proposal for a 1st-class, officially-supported CSS package

[Richard Feldman]

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 justify its inclusion. I don't think this will
ever clear that bar. :)

On Wed, Sep 14, 2016, 8:54 AM suttlecommakevin 
wrote:

> Hey Nick,
>
> I linked to the source implementation in my original post, but it does
> overlap the API.
>
> Noah,
>
> > burdening the compiler with excessive language features.
>
>
> I don't see how supporting CSS via native primitives is burdening the
> compiler.
> "Excessive" seems diametrically-opposed to what I'm suggesting.
>
> Again, I simply cannot see Elm justifying itself as a front-end language
> while not having a proper story for CSS.
> This statement feels like a placeholder, because it's certainly not a
> modern perspective.
>
> > There is no Html.Styles module because best practices for working with
> HTML suggest that this should primarily be specified in CSS files. So the
> general recommendation is to use this function lightly.
>
>
> @Evan, @Richard, I'd love your feedback here.
>
> *KS*
>
> --
> 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/vvJGw1u7NVQ/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: Sequence equivalent for Result type

[Richard Feldman]

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 it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Richard Feldman]

Here's a primer on Elm modules:
https://dennisreimann.de/articles/elm-modules-import.html

Indeed, "component" and "child" are not first-class constructs in Elm, and
so can mean different things to different people. Sorry for the confusion!

I'm going to make a point to start discussing things using terms that have
first-class language support, and see how that goes. :)

On Sun, Aug 28, 2016, 11:58 AM Nick H <falling.maso...@gmail.com> wrote:

> Well, "module" is a keyword in Elm, so I really hope everybody who knows
> Elm knows exactly what this is!
>
> 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 interaction between two update
>>> functions...is there some way to rephrase it in terms of how those two
>>> update functions interact?
>>>
>>
>> Richard, this has been a huge area of confusion for me in the
>> child-parent discussions that I've been following over the past few months!
>> What's a "module", what's a "child", what's a "component"? Everyone seems
>> to have different mental models for what these things are include me :)
>> ... resulting in some muddy and inconclusive discussions.
>>
>> ... just a observation from someone in the Peanut Gallery.
>> Carry on! This is a fun thread :)
>>
> --
>>
> 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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/_cfOu88oCx4/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.

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

[Richard Feldman]

>
> 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 this and I'm still not sure what 
it's saying. :x

That's totally on me, but I'm quickly becoming convinced that Evan's view 
of the term "components" 
 
is dead-on: our speaking in terms of "components" seems to result in way 
more confusion than positive outcomes. I'm on board with the idea that we 
should stop using it to describe portions of Elm programs, and instead 
focus discussions on terms whose definitions are clearly applicable: 
modules, functions, data, and the first-class Elm Architecture building 
blocks of Model, Msg, update, and view.

I gather that this is has to do with an interaction between two update 
functions...is there some way to rephrase it in terms of how those two 
update functions interact?

-- 
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] A more concrete question about API design

[Richard Feldman]

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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Richard Feldman]

>
> 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 into a 
different module is typically trivial and uncontroversial.

You're talking about entire model/view/update triplets that have different 
Msg types and are responsible for their own isolated state, though, which 
is a totally different thing. :)

if you wanted to subdivide some of the major sections into sub-modules, 
> would you have them stop using Platform.Cmd to communicate upward
>

Oh I definitely would only use Cmd to communicate directly to the Elm 
Runtime for things like effects and JS interop. I don't think it's the 
right tool for organizing internal Elm code in an application. I would use 
Msg for that, and things like Html.App.map and Cmd.map to facilitate that 
if necessary. :)

AppCommand seems like overkill. We need to prioritize our HTTP requests. Do 
we really need a drop-in replacement an entire foundational core library to 
do that? Why not just say "we have a business need to do HTTP requests in a 
certain way, so everybody on the team, use this way instead of making 
vanilla elm-http calls" instead?

-- 
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: A more concrete question about API design

[Richard Feldman]

>
> 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, I feel very comfortable endorsing 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.

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

[Richard Feldman]

>
> 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 for them as a solution*.
>

> *It feels like it gets at the sort of problem for which there ought to be 
> a design pattern* — i.e., structure your types and functions like this to 
> solve this sort of problem.
>

You seem very determined to invent a problem to solve, and then to ask the 
community for assistance solving it. My repeatedly pointing this out in 
other threads has obviously not dissuaded you.

Maybe that's fun for you, but I would hate to see a beginner read this post 
and think "maybe I need custom effect managers to write a scalable Elm 
application," which is *insane*.

Anyway, carry on - I just want to make it clear to anyone reading this 
thread that this is just the OP creating puzzles to solve. If anyone 
reading this is wondering whether it applies to you, don't worry: it 
doesn't.

-- 
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: Design of Large Elm apps

[Richard Feldman]

>
> 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 concept, and my recommendation takes it into account.

Having multiple people working on the same part of the code base comes up 
for us all the time!

It's totally fine. Nobody wants to reorganize our code base afterwards. :)

I get that you are worried about this in theory, but what I'm saying is 
that in practice we frequently do the thing you're saying is should be 
painful, and we've found that it actually just isn't.

-- 
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: Composability without extensible records

[Richard Feldman]

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 speed is an Int, I can infer that Slider's Msg looks like 
this:

type Msg = ChangeValue Int

A good question at this point is: *how much of Slider's state must be 
synchronized *with other state in the application?

For example, if Slider had some sort of visual flourish like "every time 
you drag it, it changes color," that state would not need any 
synchronization with other parts of the app. The slider would change color 
when you dragged it, and the rest of the application would neither know nor 
care.

The Slider's value is not independent like this. If you put a slider on a 
page and its value changes, but no other code ever finds out that its value 
changed, then the slider is useless! Its value needs to be synchronized 
with other state in order to be useful.

Since Slider has no other state besides this value, then Slider's state is 
*100% 
synchronized* with other state. In a case like this, you have two options 
for keeping it in synchronized:

1. Give Slider its own Msg, and translate between its Msg and its caller's 
Msg
2. Do not give Slider its own Msg, just have its view accept a Msg 
*constructor* as an argument.

The second option is simpler. Here's how that would look:


viewSlider : (value -> msg) -> value -> Html msg


Now we can change Profile's Msg to this:

type Msg =
  WaypointConfMsg Int WaypointConf.Msg
  | *SetSpeed Int*


...and render the slider like this:

viewSlider SetSpeed currentSpeed

So now Slider no longer has its own Msg, it just says "hey caller, tell me 
how to wrap my values in your Msg type, whatever that might be, and we're 
cool." Now instead of Slider being a Model, a Msg, an update, and a 
view...it's just a view! :)

Let's look at Waypoint next:

WaypointConfMsg idx msg' ->
case msg' of
  WaypointConf.ChangeDateOrTime _ ->
{ model | profile = newInternal, shared = Trip.changeOpDate 
model.shared idx <| getDate idx model newInternal }
  WaypointConf.SameDateAndTime _ ->
{ model | profile = newInternal }

Like Slider, its state is still *100% synchronized*, meaning it also 
doesn't need its own Msg. We can convert Waypoint into a view function 
(which accepts a "here's how to wrap things as a Msg" function just like 
Slider did—or maybe two of those functions, since there are two things 
Waypoint can change), at which point we no longer need a Waypoint Msg, 
Model, or update. Only a view.

Finally, since Profile only has Waypoint and Slider inside it, and since 
Profile has no independent state to track either, we can give it exactly 
the same treatment as what we did for Waypoint and Slider.

To summarize how I'd recommend organizing things:


*Current*

WaypointConf - Model, Msg, update, view
Slider - Model, Msg, update, view

Profile - Model, Msg, update, view

App - Model, Msg, update, view


*Proposed*

WaypointConf - view
Slider - view
Profile - view

App - Model, Msg, update, view


Hope that helps! :)

-- 
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: Composability without extensible records

[Richard Feldman]

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" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/NPOcF4Dle2w/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: Composability without extensible records

[Richard Feldman]

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Composability without extensible records

[Richard Feldman]

>
> 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
  , table : Table.InternalModel
  , profile : Profile.InternalModel
  }

If Profile only needs a subset of the model, then its nicest implementation 
will be a standalone view function. I would not write type alias Model for 
profile; instead I would do this:

viewProfile : List Route -> Maybe Int -> InternalModel -> Html Msg

If you need to use it on multiple pages, i.e. its return type needs to be Html 
msg instead of Html msg , then give it an extra parameter so the caller can 
request its Msg of choice. For example, supposing profiles can set hovered 
(which is a Maybe Int) in response to a mouse event, I would write this:

viewProfile : (Maybe Int -> msg) -> List Route -> Maybe Int -> 
InternalModel -> Html msg

See my next answer for links on how to take this further iff you need to.

> Just break it into modules so your similar functions are grouped together 
>> in files.  Use them just like you already are.  
>>
>
> The part I don't understand is: how do you create UI components that 
> maintain their internal state without nesting them as child components?
>

You don't; since the Model is the single source of truth for application 
state, nesting is how you organize that state.

Check out elm-autocomplete 
 and the API design 
session that went into it  for 
the right way to do reusable widgets!

Is there some public code that shows this pattern in action?  

It would be wonderful to look at something that feels like it needs to be 
> split up and see a version that is flat. 


I don't know of one offhand, but I'm realizing I should put in the effort 
to develop one so I can show what I mean instead of trying to describe 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: Composability without extensible records

[Richard Feldman]

For sure! :D

On Tue, Aug 23, 2016, 2:51 PM OvermindDL1 <overmind...@gmail.com> wrote:

> That is quite true, taking only the parts the function needs via matching
> out `{ parts, of, a, model }` is quite nice and extendable as needed.  :-)
>
>
> On Tuesday, August 23, 2016 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 to #2, so my macro-level suggestion would be to go
>>>> back to #1. :)
>>>>
>>>
>>> #1 also ends up making utterly *huge* model and message unions though,
>>> with extremely non-reusable parts.  :-)
>>>
>>
>> Regarding re-usable parts, I definitely recommend making things reusable
>> on an as-needed basis. Splitting out a helper function takes about two
>> seconds. ;)
>>
>> As for big models, they are easy to maintain in Elm. *I highly recommend
>> big models!*
>>
>> At work we have 36,000 LoC of production Elm. One of our most complicated
>> pages has a Model with 55 fields in it, and a Msg with 40 type
>> constructors, and it feels *nice to maintain*. A year ago it was a bunch
>> of nested React components and everyone dreaded touching it. Now we make
>> changes to it all the time and it's no big deal.
>>
>> Having that big a Model and that big a Msg sounds like it ought to be
>> painful, but in practice, it's actually great. We don't talk about
>> splitting it up because there's no pain point. I understand the reflex to
>> eagerly split things up, but as counterintuitive as it sounds, I think it's
>> the exact opposite of what leads to a good experience in Elm. :)
>>
>> "If it ain't broke, don't fix it" is a good mantra here.
>>
> --
> 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/NPOcF4Dle2w/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: Composability without extensible records

[Richard Feldman]

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 ends up making utterly *huge* model and message unions though, 
> with extremely non-reusable parts.  :-)
>

Regarding re-usable parts, I definitely recommend making things reusable on 
an as-needed basis. Splitting out a helper function takes about two 
seconds. ;)

As for big models, they are easy to maintain in Elm. *I highly recommend 
big models!*

At work we have 36,000 LoC of production Elm. One of our most complicated 
pages has a Model with 55 fields in it, and a Msg with 40 type 
constructors, and it feels *nice to maintain*. A year ago it was a bunch of 
nested React components and everyone dreaded touching it. Now we make 
changes to it all the time and it's no big deal.

Having that big a Model and that big a Msg sounds like it ought to be 
painful, but in practice, it's actually great. We don't talk about 
splitting it up because there's no pain point. I understand the reflex to 
eagerly split things up, but as counterintuitive as it sounds, I think it's 
the exact opposite of what leads to a good experience in Elm. :)

"If it ain't broke, don't fix it" is a good mantra here.

-- 
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: Composability without extensible records

[Richard Feldman]

 

> 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 
> time now.
>
> I would really appreciate any thoughts on this.
>

My main thought here is that I have had two kinds of experience building 
Elm applications:

   1. Structuring my application as simply as possible - starting with one 
   model, one view, and one msg type, not creating any "components" or 
   distributing state management in any way - and not worrying about 
   boilerplate or scaling problems I don't have.
   2. Doing something fancier than #1.

I have had a wonderful time with #1, and it has scaled incredibly well at 
work.

#2 has brought me nothing but pain and unhappiness.

You are on the road to #2, so my macro-level suggestion would be to go back 
to #1. :)

-- 
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: Basic behavioral composition

[Richard Feldman]

>
> `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 limitations 
> require it to be this noisy.  :-)
>

Yeah, elm-mdl has very specific and unusual design goals (in part because 
of ways MDL differs from other UI frameworks, and in part because of the 
author's goal for how to present MDL in a DSL) that make it substantially 
different from every other project in the Elm world...I would not look at 
its design and think "ah, this is probably what I want to do for my 
project!" because the opposite is far more likely. :)

-- 
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: Basic behavioral composition

[Richard Feldman]

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 configuration and returns the button we need:

fancyButton : { label : String, icon : String } -> Html msg
fancyButton { label, icon } =
-- Implementation goes here

Done!

In a language where refactoring is nice, you can and should reach for 
simple solutions when the problem is simple.

If the problem gets more complex later, you can then revise from a position 
of knowledge: you'll know *precisely how *it's more complicated, and that 
gives you the information you need to end up with the nicest API possible.

Conversely, trying to design an API to fit nebulous theoretical future use 
cases essentially means going in blind, and it's a recipe for unnecessary 
suffering in Elm. :)

-- 
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: Design of Large Elm apps

[Richard Feldman]

>
> 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 sense. Separating business logic from 
UX logic concerns does not require rearchitecting how your application is 
structured, nor should it. In this case, the way to pay heed to Dijkstra's 
advice is not to *create complexity* out of fear. :)

it could be that business logic belongs in Effects Managers. The 
> documentation around Effects Managers, however, suggests that they should 
> not be created all that often and that would be an odd stance for what 
> would be a standard part of a larger program. The second is to put the 
> business logic layer in as a wrapper around the view layer. That, however, 
> requires a rethink of commands and subscriptions to embrace something more 
> like the more general request concept with them really representing a 
> request for the next layer up to do something or provide some information. 


Nah, these are both solutions in search of a problem. I sometimes wonder 
whether the actual root issue here is that I'm saying "you should just 
build things and then divide later in response to specific pain points" but 
that's a really boring (however correct) answer to what would otherwise be 
a fun problem to try and solve. ;)

I'm not the only one saying this, by the way. Erik Lott is developing a 
large Elm SPA and his recent post 
 echoes 
the same "this is the wrong thing to spend time worrying about" sentiment 
I've been repeating.

tl;dr I hear you, but this concern doesn't materialize in practice. Elm has 
some things yet to work out (DOM APIs, how code splitting should work, 
etc), but architecture is not one of them.

We're all set on that front, so let's go build things! :)

-- 
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: We need a clearer story on architecture

[Richard Feldman]

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 easier to 
> maintain and understand, go ahead and do that. Whether your component is 3 
> files, or a single file shouldn't change your overall architecture - it's 
> just a horizontal partitioning of functions.
>

Totally agree! I tried to present this advice on another thread 
 but 
I'm not sure I said it as well as you just did. ;D
 

> I'm not sure what you mean by framework - do you mean elm-parts? If so, 
> just forget about that for now and connect your components manually. It's 
> not a big deal.
>

100% agree.
 

> as the SPA transitions from page to page, we load only the data that is 
> required for that page - We have no central business data in our app, 
> because our server itself serves acts as the single source of truth.
>

+1 to this too

If you're using websockets to update your business model, go ahead and do 
>> that - the model will be automatically reflected in the view. *Your view 
>> shouldn't know anything about websockets.*
>>
>
Strongly agree! Only update should know or care that websockets are 
involved.

I would second the need for better "official" documentation in Elm for 
> folks getting started. There is a learning curve to Elm, but once it 
> "clicks", it'll be more obvious how to piece your application together.
>

I think part of the challenge is figuring out where the gaps are. Threads 
like this are super helpful in surfacing specific questions, so HUGE thanks 
to Oliver for posting 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: Design of Large Elm apps

[Richard Feldman]

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


It's not *necessarily* a bad idea, just not the first thing you should 
reach for. Or the second thing you should reach for. Or the third thing you 
should reach for.

The first three things you should reach for are, in no particular order:

   1. Splitting view into smaller functions (without reorganizing Model or 
   update)
   2. Splitting Model into smaller values (without reorganizing view or 
   update)
   3. Splitting update into smaller functions (without reorganizing Model 
   or view)
   
Do one of these 3 things, one at a time, over and over, until either you're 
thinking "I need to split out some of this to reuse it elsewhere" (in which 
case you enter the realm of API design, and there is no one-size-fits-all 
answer to what you should do next), or you find yourself thinking "even 
after these small refactors, there is a big chunk of code that still feels 
unwieldy, and it's self-contained enough that I could separate it out into 
essentially its own little application, and have it communicate with the 
rest of the application, and that communication overhead sounds like it 
would be worth it."

As the guide says:

what happens when our code starts getting big? It would be crazy to just 
> grow your Model and update functions endlessly. This is where Elm's 
> module system comes in.


The nested counter is a demonstration of how to do this technique *once 
your code base grows crazy enough to make it seem worthwhile*, but it's 
super common to build something straightforward enough that it never needs 
this kind of nesting at all!

I get where you are coming from in saying that the update function becomes 
> essentially fifty smaller functions. Some of the questions on modularity 
> then stem from whether you ever expect someone to read through and consider 
> an entire Elm module or whether you expect that people will make changes to 
> pieces of code within a module and simply ignore the rest of it. The latter 
> is probably common no matter what. To me, it's a question of whether the 
> former should be viable or whether it's basically considered irrelevant as 
> a practice.
>

In my experience the latter hasn't been a problem, so it doesn't seem like 
looking for a solution would be a good use of anyone's time. ;) 

-- 
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: Design of Large Elm apps

[Richard Feldman]

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

They definitely get big, but one surprising thing I've learned is that a 
gigantic update function basically reads like a bunch of small, decoupled 
functions.

For example, here are a few cases from one of our update functions at work:

ToggleDescriptions ->
( { model | showDescriptions = not model.showDescriptions }, 
Cmd.none )

SetGradeFilterTooltipVisibility visibility ->
( { model | gradeFilterTooltipVisible = visibility }, Cmd.none )

OpenQuestionTooltip questionId ->
( { model | tooltipShowing = Just questionId }, Cmd.none )

CloseTooltips ->
( { model | tooltipShowing = Nothing, gradeFilterTooltipVisible = 
False }, Cmd.none )

One way to look at this is that it's 12 lines of code inside an update 
function.

Another way to look at it is that it's basically four one-liner functions, 
in terms of how decoupled they are and how easy it is to tell what they're 
doing.

That's what it feels like maintaining these. If I want to know what 
CloseTooltips does, I go look up its implementation. As it happens, its 
implementation lives inside a long update function, but it wouldn't have 
been any easier or harder to look up if the implementation happened to be a 
one-liner function instead. Obviously pattern matches aren't as composable 
as functions, but that doesn't make it any harder to follow what they're 
doing.

In practice a long update function feels like a lot of short, decoupled 
functions: really pleasant to maintain. :)


I took these four examples from our longest update function. It's about 600 
LoC, and its Msg is a union type with about 50 constructors.

One way to look at that is "that function is way too big by the heuristics 
I'm used to!"

Another way to look at it is "that will feel about the same as maintaining 
50 small independent functions, each an average of 12 LoC in length. Sounds 
like it'd be really easy to tell what each of them is doing!"

And so it is. :)

-- 
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: Design of Large Elm apps

[Richard Feldman]

>
> 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 api) 
> or is your code organized into many smaller applications, each served on a 
> single server rendered html page (routing handled server side - maybe 
> initial data is provided directly through Elm.fullscreen rather than 
> hitting an api).
>

The latter, although it's important to note that it's the same granularity 
either way. We started building our Elm code base on top of a large legacy 
non-SPA Rails app, so the way each individual page works is that Rails 
renders some JSON in a 

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

[Richard Feldman]

>
> 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 in it, and neither should Model.

Maybe I don't understand the Elm Architecture, but as far as I know every 
> Elm module has it's own model, view and the update function.
>

For our (enormous) Elm code base at work, most pages (as in an individual 
URL an end user can visit) have one model, one view, and one update 
function. There is no "parent-child communication" on these pages.

We had Elm in production for months before we encountered the first time it 
was a good idea to have a "parent-child" relationship, and it was over 6 
months (and well over 10,000 lines of Elm code) before we found the second 
case where it was a good idea.

Here is what I recommend:

   1. For a given page, start with one model, one view, and one update.
   2. If one of those (model, view, or update) gets too big and starts 
   feeling unwieldy, *subdivide only that thing.* For example, if view 
   feels too big, split it into some helper functions but *don't touch 
   model or update.* If update feels too big, same thing - split out helper 
   functions but don't touch the view or model. If your model feels too big, 
*reorganize 
   only the model*. Split it from one record into some nested records, but 
   don't rearchitect update or view.
   3. Any time you find yourself thinking "I bet this will be nicer if I 
   split it into its own model/update/view" your next thought should be 
   "whoops! That's a classic beginner mistake. My code will actually be worse 
   if I do that. Glad I didn't do that!" (It's an easy trap to fall into - I 
   fell into it myself, and fell hard, as a beginner.)

Basically, whenever I meet someone who is new to Elm and asking about 
parent-child communication, what I really want to say is "a parent-child 
relationship in an application is very rarely the right tool for the job, 
and is almost certainly not what you want as a beginner. How can I help you 
avoid falling into the same trap I fell into when I was just starting out?" 
:)

-- 
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: Elm Generated Files are Quite Large

[Richard Feldman]

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 thing is, it's the sort of thing most people want less than 
things like server-side rendering or better debugging capabilities.

It'll be the most important thing someday, but probably not soon. :)

On Monday, August 8, 2016 at 8:59:22 PM UTC-7, Austin Horning wrote:
>
> Using the latest version of elm, even the simplest of apps come out to 
> greater than 7000 lines and 100kb of generated javascript. This seems to be 
> because all imported libraries are included regardless of whether or not 
> they are used, and upon digging into the generated code, it would seem that 
> it would not be completely unreasonable to leave about half of that code 
> unused even in larger projects. If elm employed some sort of pruning 
> strategy to find and remove unused code at compile time, then thousands of 
> lines could be removed from the generated javascript. There are a couple 
> ways to go about this as far as I can see.
>
> The first would be to have a sort of lazy including strategy, which would 
> build a sort of dependency tree as function calls are detected. This method 
> has the advantage of being quick and more aware of the elm compilation 
> process(being a part of the basic compilation process), which could lend to 
> it being more extensible.
>
> The second strategy is to build the javascript as it is already done. Then 
> make a few passes with another tool and remove dead code from the file in 
> that fashion. This method might be slower, but it would not interfere with 
> the current compilation process.
>
> Don't get me wrong. 100 kb is not that bad, and I certainly would not see 
> this as a super high priority. The possibility is that if it could be 
> incredibly small at compile time, it would be incredibly practical to embed 
> elm apps everywhere(even multiple in one page, potentially). If the 
> compiler was responsible, it would likely be much more efficient than 
> UglifyJs(given the nature of JS) at dead code removal and the option to run 
> through Uglify is still available. If I am a business and you tell me that 
> I can save 90% on CDN costs and cut page load time in half(just in terms of 
> download time) by switching to elm, that could be an incredibly convincing 
> argument. 
>
> Has anyone considered implementing something like this?
>

-- 
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] Easy first contribution: reproducing a record error message

[Richard Feldman]

If anyone is looking for a first Elm contribution, a SSCCE 
 for this issue 

 is 
pretty low-hanging fruit! :)

-- 
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 [ 1..5 ] exist?

[Richard Feldman]

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 1,2,3,4?" etc.

I'd rather drop this special syntax in favor of a simple function:

List.range : number -> number -> List number

It'd make for one less piece of syntax to learn, would simplify the 
compiler, and personally I'd find it more convenient to use than the 
special syntax. This way when I want to know how it works I can look it up 
in the List docs like normal!

Thoughts?

-- 
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: Draft blog post - "How to Use Elm at Work" - looking for feedback

[Richard Feldman]

 

> 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 
> simple Elm code that outputs a form that looks like it came from 2016 and 
> go "oops, my bad, sorry for wasting everyone's time". 
>

Sure - I even wrote a blog post 

 about 
it. :)

That post includes examples in the form of SignupForm.elm 
 and the 
styles that go with it 
.
 I 
didn't bother inline the styles into Elm, but obviously that's a copy/paste 
and find/replace job.

All of Graphics.Input was dropped


Ah, I did not know that! My mistake. You're right, Janis.

Regarding elm-mdl. I am well aware of the release of 6.0.0. I was not 
> arguing that people are not still fighting. 
> What I said was that "*they were explicitly or implicitly dismissed"*. 
>
If you want me to be more explicit, I was thinking about the discussions 
> around boilerplate that prompted elm-parts, the difficulties around 
> geometry that prompted debois/elm-dom.
>

Facebook released React with a built-in, dead-easy way to do reusable 
stateful components: each component has its own local mutable state.

However, they at Facebook weren't satisfied with how this UX scaled, so 
they also released Flux as a more scalable way to manage state.

Many people weren't happy with Flux, though, so they started looking 
elsewhere, for example to ClojureScript, leading to Omniscient.js 
 based on David Nolen's 
cursor-based state management model for Om .

David Nolen himself ended up moving away from that with Om Next 
, which abandoned 
cursors in favor of a custom state management system based on Relay, 
Falcor, and Datomic. Obviously not everyone agrees with him; Omniscient.js 
is still under active development. Its last commit is 2 days ago.

Others looked to Elm, like Dan Abramov, who created Redux 
. It's very popular in the React world, 
although since Facebook hired Dan, he's been working on ways to make React 
not need it anymore. That seems likely to result in the release of a new 
way to do things , whenever whatever it is gets 
released.

Others thought Redux was too heavyweight and trying to do too much at once, 
which has led to Choo , a 
self-described 
 
adaptation of Elm 0.17's architecture in JS.

I've spent hours discussing these things with Jafar Husain at Netflix, who 
thinks Observables are the answer. See for example rx-react 
 or Andre Staltz's popular 
Cycle.js .

This is to say nothing of how Angular manages state. Or Ember. Or Aurelia. 
Or Vue.

My point is this:

*Every single community that's involved in making browser-based UIs is 
flooded with conflicting viewpoints on how reusable stateful components 
should be done.*

There is not some glaringly obvious answer that will make everyone happy. 
It does not exist.

History strongly suggests that in this area,* making one group of people 
happy makes others unhappy.*

I was on a Skype call several months ago where Søren and Evan had an 
extended discussion about his experiences developing elm-mdl. The fact that 
Evan did not end up doing things the way you think he should is not a 
reflection of Evan being dismissive of Søren's experience, it's that *reusable 
stateful components are a minefield of tradeoffs*.

Personally I think when one finds oneself in a minefield, it is wise to 
tread carefully. :)

>

-- 
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: Try out the 0.17.1 beta

[Richard Feldman]

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