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

[Erik Lott]

>
> 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 
>
> 
>."
>
>
>1. 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.
>
>
Richard, I think it's only your broad use of the word "*Elm Applications*" 
that is a little misleading for some folks.  When you say "Elm 
Application", maybe you mean: Elm applications like we write at NoRedInk 
(non-SPA applications). ie. each page of the web app is served from a ruby 
on rails server, and that page may include an Elm app(s). In your context, 
I agree with your advice.

When other folks are talking about "*Elm Applications*", they're talking 
about Single Page Applications. In the context of an SPA, the 
Model-View-Update triplet will indeed be a unit of composition for an app - 
each logical page within the app will likely be a triplet. Of course, your 
advice still applies to the individual "pages" within an SPA, but not 
necessarily the overall architecture itself.

The distinction is important, because it's obviously confusing folks. 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.



On Wednesday, April 19, 2017 at 1:27:09 PM UTC-4, Richard Feldman wrote:
>
> 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

[Rehno Lindeque]

>
> *I have not seen the reverse happening.*


I usually try not to get involved in long threads like this nowadays, but I 
feel obligated to quickly mention that we were also recently pretty happy 
with a recent refactor that reduced the boilerplate in an internal 
documentation page. (We haven't published this as a package, we're still 
building some experience with it and mostly using the inverted control that 
folks generally recommend).

doc =
layout6
Symbol.component
Footprint.component
PackageOverlay.component
(SourceEditor.Form.component (SourceEditor.configure 
Example.sourceEditorConfig))
(PartEditor.Form.component Example.partEditorConfig)
ConsignEditor.Form.component
(\symbol footprint packageOverlay sourceEditor partEditor 
consignEditor ->
docBody []
[ div []
[ docSection "components"
"Components"
[ docSubSection "symbol" "Symbol" [ symbol ]
, docSubSection "footprint" "Footprint" [ footprint 
]
, docSubSection "packageoverlay" "PackageOverlay" [ 
packageOverlay ]
, docSubSection "sourceeditor" "SourceEditor" [ 
sourceEditor ]
, docSubSection "parteditor" "PartEditor" [ 
partEditor ]
, docSubSection "consigneditor" "ConsignEditor" [ 
consignEditor ]
]
]
]
)

main =
program
{ init =
doc.init
( force Example.symbol
, force Example.footprintFlags
, force Example.packageOverlayFlags
, force Example.sourceEditor
, force Example.partEditor
, {}
)
, subscriptions = doc.subscriptions
, update = doc.update
, view = doc.view
}

This was a fantastic reduction from the previous boilerplate and I'm really 
pretty happy with how it turned out (but I don't want to hold this 
particular example up as canonical, this is still an experimental approach 
with its own caveats, like any other architecture).

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

[Chad Woolley]

>
> 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!
>
> Please do!  When we were learning Elm, our team spent many cumulative days
of debating and discussing what is the "right" high-level architecture as
we developed and evolved more SPAs.

This thread shows that the answer is a definitive "it depends".

It would be great to have a summary of these approaches, with code
examples, in an easily-discoverable, "official" (referenced somewhere from
Elm docs or website) place.  Or maybe in a book on Elm ;)

-- Chad

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

[Oliver Searle-Barnes]

You've definitely given me some great advice along the way, I'm very 
grateful!

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.


On Thursday, 20 April 2017 21:20:47 UTC+2, Richard Feldman wrote:
>
> 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]

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

[Yosuke Torii]

Marek

This reply is only to my part. Did not read other parts.


> Maybe you've noticed that I haven't commented your example with
> reusability. That was on purpose because telling when and on what you
> should use it is completely different topic. For sure it can be used for
> integrating community components. It can be used anytime you're using
> Cmd.map Html.map and Sub.map. That's actually beauty of abstraction that it
> can be applied regardless of your domain. Same way s you can List.map view
> over List of data to turn them into view you can use this to map date
> picker's api to app and anything else. My intention is not telling anyone
> when and on what to use it. It's just super thin helper for doing (a, Cmd
> b) -> (c, Cmd e) with the use of functions.


I'm strongly against this way of thinking.

Telling nothing about who to use, when to use or what to use for is
the *easiest
*way. But does it make anyone happy? As you say, we can use Cmd.map,
Sub.map and Html.map everywhere but we are happy with the fact `view`
function does not return `Cmd msg` so you can say there must be no side
effects in view.

"That's actually beauty of abstraction that it can be applied regardless of
> your domain."


Yes it *can *be, but *should not* be. We (...not every one but at least
many of us including me) found NOT everything is a component. The old TEA
document was doing just like you; "There is a pattern that is sometimes
useful". I thought "oh cool, everywhere in my app should be organized like
this" ...and I regretted it later. Things got needlessly complicated. For
example, some components required many options like { onSelect, onChange,
... } and the parent component just translated to that layer's msg. But
actually that component was used only once. I refactored that component to
have some knowledge about the application and the code got significantly
simpler than before. After that, I've get that better habit to think like
"okay, this is just a view, no need to have state for now".

It's just super thin helper for doing (a, Cmd b) -> (c, Cmd e) with the use
> of functions.


Maybe you need this function? This is thinner.

andThen : (model -> (model, Cmd msg)) -> (model, Cmd msg) -> (model, Cmd
msg)
andThen update (model, cmd) =
  let
(newModel, newCmd) =
  update model
  in
newModel ! [ cmd, newCmd ]


This function enables separating concerns so you can apply many operations
one by one. I'm recently using this and now `update` function is cleaner
than ever. If your core problem is this, this might be the answer, not
components. So I wanted to know what concrete problem you are really want
to solve.



2017-04-20 23:22 GMT+09:00 Marek Fajkus :

> Richard,
>
> 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.
>
>
> I struggle to understand to see where is a difference. Html.program
> constructor is record of functions as well. Sometimes it's just nicer to
> have arguments named. Also as docs and code clearly says it's just
> composing functions, nothing more. init with init, update with update... I
> think saying that pure function inside record is by any mean different than
> pure function living in module's namespace is really misleading. For
> instance this using elm-decode-pipeline
> 
>  you're lifting (operation called pure in Json.Decode it's succeed)
> function (usually type constructor) to `Decoder` context. And it's fine
> because this is how functional programming work.
>
> You have mention experience with teaching beginners on many occasions.
> That's fair point I don't have that much experience teaching beginners
> however I have quite a lot experience with folks doing side project in elm
> being scared of complex apps.
> For instance our HR have contacted Tomas  just
> few days ago. Since he knows me from elm community meetups he DM. We're
> both czech (and was speaking czech) so I have to translate it (adding
> original and translation:
>
> czech:
>
>> No na to zatím nemám :) jsem Funkcionalni lama :)
>
>
> english:
>
>>  I can't do this :) I'm not that skilled in functional programming
>
>
> Than I spend 2 hours trying to convince him that there is nothing to be
> afraid of.
>
> Just on this Tuesday he wrote me again without previous warning (this is
> before interview which he will have next week):
>
> cze:
>
>> Třeba se to vyřeší samo a nevezmete mě. Alespoň pak naboucham nějaké
>> zkušenosti do zásoby na příští kolo ;)
>
>
> eng:
>
>>  Maybe it will resolve itself and will not hire me. At least I will have
>> time to gain more experience on next round.
>
>
> *THIS IS COMPLETELY CRAZY!*
>
> We've already lost one talented guy because he was afraid that he won't be
> able to do anything on such scale! From my experienc

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

[Oliver Searle-Barnes]

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

This is a fairly high view of our app and how it's architected but 
hopefully it's a useful level of detail (I've mentioned it a couple of 
times already but here's a rough gist of the folder/file structure we use 
https://gist.github.com/opsb/d0977bcb30b42302f3f2dc3daf0befec). 

To give you a bit of our context our product is an embeddable web app that 
adds discussion rooms and news feeds to your website. We have Phoenix on 
the backend and we're using elm-phoenix for integration in the client. 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. 

These requirements led us to an architecture where we have a single Store 
which handles data synchronisation and then several mini-apps which use 
this Store. The Store responsibilities include: subscribing to data feeds 
from the backend, caching results, mutating data in the backend and latency 
compensation (otherwise known as optimistic UI). At the top level these 
mini-apps are organised into complete pages. The pages themselves don't do 
much, they're mapped to urls and combine a set of mini-apps. Each mini-app 
is then responsible for it's own lifecycle (e.g. Loading/Loaded/Error). 

While the requirements have forced have led us towards the mini-apps design 
we've found that they're a great way to organise the codebase, developers 
can concentrate on a particular mini-app and get up to speed very quickly. 

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

[Marek Fajkus]

Richard,

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.


I struggle to understand to see where is a difference. Html.program 
constructor is record of functions as well. Sometimes it's just nicer to 
have arguments named. Also as docs and code clearly says it's just 
composing functions, nothing more. init with init, update with update... I 
think saying that pure function inside record is by any mean different than 
pure function living in module's namespace is really misleading. For 
instance this using elm-decode-pipeline 

 you're 
lifting (operation called pure in Json.Decode it's succeed) function 
(usually type constructor) to `Decoder` context. And it's fine because this 
is how functional programming work.

You have mention experience with teaching beginners on many occasions. 
That's fair point I don't have that much experience teaching beginners 
however I have quite a lot experience with folks doing side project in elm 
being scared of complex apps.
For instance our HR have contacted Tomas  just 
few days ago. Since he knows me from elm community meetups he DM. We're 
both czech (and was speaking czech) so I have to translate it (adding 
original and translation:

czech:

> No na to zatím nemám :) jsem Funkcionalni lama :)

 
english:

>  I can't do this :) I'm not that skilled in functional programming


Than I spend 2 hours trying to convince him that there is nothing to be 
afraid of.

Just on this Tuesday he wrote me again without previous warning (this is 
before interview which he will have next week):

cze:

> Třeba se to vyřeší samo a nevezmete mě. Alespoň pak naboucham nějaké 
> zkušenosti do zásoby na příští kolo ;)


eng: 

>  Maybe it will resolve itself and will not hire me. At least I will have 
> time to gain more experience on next round.


*THIS IS COMPLETELY CRAZY!*

We've already lost one talented guy because he was afraid that he won't be 
able to do anything on such scale! From my experience it's easier to hire 
js developer and teach him elm than to hire folks from community because 
they are so afraid when we show them js implementation we're porting.

Yosuke,

So Marek's library is for organizing entire app, not about using external 
> library.


Maybe you've noticed that I haven't commented your example with 
reusability. That was on purpose because telling when and on what you 
should use it is completely different topic. For sure it can be used for 
integrating community components. It can be used anytime you're using 
Cmd.map Html.map and Sub.map. That's actually beauty of abstraction that it 
can be applied regardless of your domain. Same way s you can List.map view 
over List of data to turn them into view you can use this to map date 
picker's api to app and anything else. My intention is not telling anyone 
when and on what to use it. It's just super thin helper for doing (a, Cmd 
b) -> (c, Cmd e) with the use of functions.

What I think...

Richard
is building software for learning kids (which is actually ethically super 
important mission in my opinion) where initial idea, first prototype and 
final feature might looks really really different. I can imagine this might 
be a lot about exploration and validating and reevaluating ideas. I also 
think you did mention this in one of your talks but I can't remember which 
one it was. Logically there you see value of system that is easy to reshape 
and many language features helps you there. Honestly this is really 
building ball of mud but the point sometimes there is nothing wrong with 
that.. Mud can be reshaped in few minutes. The really crazy idea in your 
field would be to do DDD since that domain is so loosely specified.

Mark
on the other hand values design patterns and architectural thinking. He has 
experiences with identifying critical concerns up front by 
analyzing obviously pretty deterministic domain. In his view of 
development there're is really not time involved. His problem didn't change 
over night he is analyzing problem which is observably same each time you 
look at it. I also think he might be into DDD (Domain Driven Design). 
Personally I'm most of the time pretty skeptical about DDD and has many 
arguments with our CTO who is also fan of DDD.

Me
For me the important thing is separation of concerns. This is actually why 
we're reimplementing that app in first place. The biggest cost in our case 
is when any new feature breaks anything existing. By that cost I mean we 
will rather send for times that much on new feature rather then being able 
to break existing one. This is due to the fact we're working with data 
where slight bug in sorting in case of some weird state in analytics tool 

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

[Oliver Searle-Barnes]

Yes we spoke about how the idea of having "sections" within a page that 
function as independent units. The idea of mini-apps seems to encompass the 
approach of splitting out the app into Pages and page Sections. I don't 
have time now but I'll try to put down a description of our app later on 
today. ICYMI I posted a gist of the rough folder/file structure we use 
at https://gist.github.com/opsb/d0977bcb30b42302f3f2dc3daf0befec

On Thursday, 20 April 2017 06:49:22 UTC+2, Richard Feldman wrote:
>
> 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]

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

[Oliver Searle-Barnes]

> I have not seen the reverse happening.

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). I'll 
try to summarise the areas where we saw an improvement. (note I've used the 
term TEA component for lack an alternative -- triplet doesn't really cover 
it as we've added additional functions into what we think of as mini-apps).

*Msgs*
The Msgs for a part of the UI were only valid once that part of the UI was 
actually loaded. Prior to nesting we had to handle the possibility of Msgs 
being created that in fact couldn't exist at a particular point in time. 

*Models*
Similar to Msgs, the state for a particular part of the UI was only present 
if that part of the UI was actually initialised. Using a flattened 
structure this led to a lot of Maybes that could be replaced by a single 
Maybe or Dict (in the case that multiple versions of that part of the UI 
could be loaded at the same tie). While it isn't necessary to introduce a 
TEA component to do this, you are already another step down the road to a 
TEA component once you do this. 

*Declarative data loading* 
Each TEA component can now specify which data it requires and it's made 
available/kept updated when that component is active. Active here meaning 
that the component has been initialised but may or may not currently be 
visible. Having this consistent approach to data synchronisation has made 
it easier to understand the data lifecycle for a particular part of the UI.

*Synchronisation of scroll state and focus* 
Each of our nested components now has a syncDom hook which is used to 
synchronise aspects of the DOM which can't be handled declaratively. Being 
able to target a TEA component rather than the whole app or e.g. a 
particular element's scroll state has proven to be a practical level of 
granularity.

*Reusable view components* 
We view these as distinct from the mini-apps that I mentioned earlier. The 
approach elm-sortable-table uses shifts some of the burden of state 
management into the client of the package. In it's case this is a good 
tradeoff. In other cases, when a component has several pieces of view state 
for instance, pushing this out to the consumer ends up with copy/pasted 
code that has all the pain that you'd expect. Sometimes the client has no 
business touching the state at all, e.g. the open/closed state of a 
dropdown menu for instance. In that case the menu is responsible for when 
it's open/closed and it needs to manage this when a user for instance 
clicks on a link in the menu (the menu needs to be closed before handling 
the click).

*Code comprehension* 
Developers are finding it far easier to navigate the codebase. They're now 
able to work on a particular TEA component and the amount of code they have 
to grok before they can get started is far smaller. Prior to introducing 
the nested structure the feedback from new developers was that they felt 
lost at sea and overwhelmed by the amount of code they had to wade through. 
Generally excuses were made and they avoided working on the Elm app. Now 
that we've moved to a nested structure they're able to concentrate on a 
small part of the app and get up to speed/make changes easily.

Our experience has been that TEA component concept that was encouraged with 
0.17 has it's place in SPAs. It appears other teams building SPAs have had 
similar experiences (although I'm not sure whether they've experimented 
with the flat approach). As Mark has mentioned it does at least provide an 
architecture which new Elm developers building SPAs can get started with. 
There may well be a flat approach that addresses some of the concerns that 
I've mentioned. Currently though it seems a somewhat illusive approach, if 
it's to be encouraged then there needs to be some more concrete advice 
regarding how to implement it. That said, aside from a little boilerplate 
(which is minimal by comparison to the actual app code) we really haven't 
felt any desire to move away from the nested TEA structure.


On Thursday, 20 April 2017 03:09:47 UTC+2, Richard Feldman wrote:
>
> 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 
>> de

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.

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

[Yosuke Torii]

I just read the whole conversation on Slack and realized what I said here
was somewhat pointless. I apologize for not reading the context.

So Marek's library is for organizing entire app, not about using external
library. If so, Richard's answer on reddit seems best fitted. About the
external libraries that have their own state, it is already answered well.

rtfeldman [3 days ago]
> the difference is that `thebritician/elm-autocomplete` is managing its own
> state because there is absolutely no possible other way to implement that
> library
> it's the last resort, not the default


I agree. It seems true from my experience too. Sometimes model, update, msg
and view are all together. But it is a special case. elm-component's API is
telling beginners as if they should always be together. Okay I completely
understand the context. It must be an anti-pattern!

Sorry again for confusing.


2017-04-20 9:21 GMT+09:00 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 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]

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

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

[Marek Fajkus]

Richard, 

this is what you said about composing update functions:
 

> I'll reiterate that thinking about application organization as "composing 
> TEA-shaped units" is neither officially recommended nor what Elm is 
> designed for...

 

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


>1. 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.
>
> *I'll use your own words:*
 

> this level of doublespeak is really uncool


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

repeating one more time:

>
>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 
>
> 
>."
>
> Well 0.16 -> 0.17 is switch from Effects to Html.program with pure 
individual functions init, update, subscribe, view. Going back to my first 
quote of you. And changing words "TEA-shaped units" with "individual 
functions" we get:  I'll reiterate that thinking about application 
organization as *individual functions* is neither officially recommended 
nor what Elm is designed for...

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


It did indeed... 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? 
 
*I'll use your own words:*
 

> this level of doublespeak is really uncool

 
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. Please don't start sending links to same Reddit 
thread once again.

I hope you don't think anyone will actually comment this one at all:

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?


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

[Mark Hamburg]

I think we have two general trains of thought regarding development here.

One is YAGNI. Let things grow organically. Refactor when it gets messy.

The other is Build for Success. Over engineer because you will probably end
up shipping the prototype and once you do it will be too late to go back
and do major restructuring.

Each has its place. Each builds for particular outcomes. Each can succeed
or fail in spectacular and unique ways. With great effort, each can emulate
the advantages of the other — ignoring the fact that the advantages are
often in terms of not needing as much effort.

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

Where this turns ugly is when it ceases to be about approaches we
individually find valuable but about how everyone should work.

Let's look at this thread. It was instigated by Marek's "components"
package which got some discussion on elm-dev and which I moved over here to
elm-discuss. The structure camp was essentially looking at this and trying
to judge whether it would help with their own structural work. The YAGNI
camp joined in and said in bold text: "*a Model-View-Update triplet is the
wrong unit of composition for Elm applications."* Not, "I (or we) haven't
found it useful" but "it is wrong". So, now we're off to the races. 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." The YAGNI camp
can argue that its statements are strongly worded in the interest of
keeping beginners away from excessive complexity. The structure camp can
argue that it needs to be vocal so that beginners understand the mess that
they may get themselves into on a refactor only as needed path.

Mark

On Wed, Apr 19, 2017 at 2:30 PM, Yosuke Torii  wrote:

> Richard,
>
>
>> 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?
>
>
> I don't know. I just answered the question why I received your message as
> "DIY every time". I'm not looking for the alternative for "component" .
>
> I covered how to grow Elm application code bases
>> ,
>> and Evan covered reuse .
>> What is the remaining problem? :)
>
>
> Again I agree to how to break the monolith and when to do it. But is any
> of those reusable things non-TEA? I find UI libraries at
> packages.elm-lang.com but they are often written in TEA manner. If it is
> not simple, how can they be instead?
>
> Sorry if you have already explained enough. Honestly it is hard to read
> whole of messages, as Noah said.
>
>
> Peter,
>
> The problem is that this approach makes it impossible (as far as I could
>> see) to implement the components that need side effects (like the old
>> RandomGif list)
>
>
> Yeah, I know. But at least, some of the UI widgets that does not have
> side-effects can be solved. As far as I can see, the discussion here is
> not on this stage yet.
>
> I think something like `mapWithCmd : (a -> Cmd msg) -> Html a -> Html msg`
> would solve it. The problem is that it allows any kind of side effects
> including HTTP. But I don't find good explanation of why HTTP via view is
> bad while random (or time stamp too?) is OK.
>
>
> 2017-04-20 5:40 GMT+09:00 Peter Damoc :
>
>>
>>
>> On Wed, Apr 19, 2017 at 11:19 PM, Yosuke Torii 
>> wrote:
>>
>>> 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.
>>
>>
>>> Also, "no components, no nesting TEA" does not answer the problem
>>> discussed here. So how can we do instead? Maybe introducing sortable-table
>>> pattern is more constructive for this discussion. I think it is a variant
>>> of TEA, managing its own state, but still keeping the form of "reusable
>>> *view*". So great!
>>>
>>
>> the sortable table is a clever component that pushed the external call to
>> update inside the view.
>> You still need what used to be the ChildMsg tag but now instead of
>> calling the Child.update and saving the state it receives the updated
>> state and just saves it.
>>
>> 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.
>>
>> The problem is that this approach makes it impossible (as far as I could
>> see) to implement the components that need side eff

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

[Yosuke Torii]

Richard,


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


I don't know. I just answered the question why I received your message as
"DIY every time". I'm not looking for the alternative for "component" .

I covered how to grow Elm application code bases
> ,
> and Evan covered reuse .
> What is the remaining problem? :)


Again I agree to how to break the monolith and when to do it. But is any of
those reusable things non-TEA? I find UI libraries at packages.elm-lang.com
but they are often written in TEA manner. If it is not simple, how can they
be instead?

Sorry if you have already explained enough. Honestly it is hard to read
whole of messages, as Noah said.


Peter,

The problem is that this approach makes it impossible (as far as I could
> see) to implement the components that need side effects (like the old
> RandomGif list)


Yeah, I know. But at least, some of the UI widgets that does not have
side-effects can be solved. As far as I can see, the discussion here is not
on this stage yet.

I think something like `mapWithCmd : (a -> Cmd msg) -> Html a -> Html msg`
would solve it. The problem is that it allows any kind of side effects
including HTTP. But I don't find good explanation of why HTTP via view is
bad while random (or time stamp too?) is OK.


2017-04-20 5:40 GMT+09:00 Peter Damoc :

>
>
> On Wed, Apr 19, 2017 at 11:19 PM, Yosuke Torii 
> wrote:
>
>> 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.
>
>
>> Also, "no components, no nesting TEA" does not answer the problem
>> discussed here. So how can we do instead? Maybe introducing sortable-table
>> pattern is more constructive for this discussion. I think it is a variant
>> of TEA, managing its own state, but still keeping the form of "reusable
>> *view*". So great!
>>
>
> the sortable table is a clever component that pushed the external call to
> update inside the view.
> You still need what used to be the ChildMsg tag but now instead of
> calling the Child.update and saving the state it receives the updated
> state and just saves it.
>
> 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.
>
> The problem is that this approach makes it impossible (as far as I could
> see) to implement the components that need side effects (like the old
> RandomGif list)
>
>
>
>
>
>
> --
> 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.

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

[Peter Damoc]

On Wed, Apr 19, 2017 at 11:19 PM, Yosuke Torii  wrote:

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


> Also, "no components, no nesting TEA" does not answer the problem
> discussed here. So how can we do instead? Maybe introducing sortable-table
> pattern is more constructive for this discussion. I think it is a variant
> of TEA, managing its own state, but still keeping the form of "reusable
> *view*". So great!
>

the sortable table is a clever component that pushed the external call to
update inside the view.
You still need what used to be the ChildMsg tag but now instead of calling
the Child.update and saving the state it receives the updated state and
just saves it.

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.

The problem is that this approach makes it impossible (as far as I could
see) to implement the components that need side effects (like the old
RandomGif list)






-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

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

[Yosuke Torii]

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

Also, "no components, no nesting TEA" does not answer the problem discussed
here. So how can we do instead? Maybe introducing sortable-table pattern is
more constructive for this discussion. I think it is a variant of TEA,
managing its own state, but still keeping the form of "reusable *view*". So
great!



2017-04-20 4:39 GMT+09:00 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 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.

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

[Noah Hall]

Hey folks,

I just want to say, it's really really really hard to reply to these
posts which are both really long and really dense. It's better to
answer in a terse, short format. This is a conversation - not a blog
post. Longer comments and responses are usually better in a blog post,
because it's quite hard to keep all the context in our heads for each
mail on a mailing list.

Regarding how to structure code for large apps, I really recommend
looking at the NRI elm-style-guide.
https://github.com/noredink/elm-style-guide#nri

The "reusable" parts are those prefixed by `Nri`. Here's an example of
what some type signatures might look like:

-- Button.elm
view : msg -> Html msg
view onClick = ...

-- Emoji.elm
type Emoji = Smile | SadFace
view : Emoji -> Html msg
view emoji = ...

-- Leaderboard.elm

type LeaderSettings field = { numberOfPlayers : Int, fields: List field }
view : LeaderSettings field -> (field -> msg) -> Html msg
view settings onFieldChange = ...


I recommend trying out this approach, and see how you like it. It
makes implementing things _so_ simple. I've tried every approach under
the sun, and seen more codebases than I can count. This is the one
that wins for me.

If anyone tries this approach, but fails to get their head around how
to refactor their code to work with it, or fails to see how it's
simpler, hit me up on Slack (eeue56) or at elm-europe or
https://osloelmday.no, and I will guarantee your code will walk away
looking nicer than it did before.

On Wed, Apr 19, 2017 at 8:50 PM, Mark Hamburg  wrote:
> The monster model design is one aspect that leads to the ball of mud code.
> Let's look at the source quote for the term big ball of mud:
>
> A Big Ball of Mud is a haphazardly structured, sprawling, sloppy,
> duct-tape-and-baling-wire, spaghetti-code jungle. These systems show
> unmistakable signs of unregulated growth, and repeated, expedient repair.
> Information is shared promiscuously among distant elements of the system,
> often to the point where nearly all the important information becomes global
> or duplicated. The overall structure of the system may never have been well
> defined. If it was, it may have eroded beyond recognition. Programmers with
> a shred of architectural sensibility shun these quagmires. Only those who
> are unconcerned about architecture, and, perhaps, are comfortable with the
> inertia of the day-to-day chore of patching the holes in these failing
> dikes, are content to work on such systems.
>
> — Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on
> Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois,
> September 1997
>
> When everything starts out in one place with access to everything else, it's
> natural to end up with everything talking to and depending on everything
> else — or at least the dependencies are less likely to be well regulated
> because there is no mechanism doing the regulation. Now, as conservative
> politicians will love to tell you, regulations get in the way and we can be
> more productive without them, so yes, this unregulated environment is
> seemingly more productive. The type system will help in detecting out and
> out errors in making changes but once things get intertwined, they become
> less amenable to significant change. That's often fine for an agile
> development model in which one focuses on small changes but 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. An approach which
> basically seems to advocate building a monolithic, intertwined codebase and
> if that gets to be too much, here are some techniques to break it down after
> the fact will work to an extent but will be fighting to apply order to chaos
> and almost all the time it will be easier for a developer trying to get a
> task done to just add a little more chaos.
>
> As for your specific advice, it includes several useful points and I've
> refactored code using those same techniques, but 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. (I guess it means use functions rather than types but
> since types are what allow us to make illegal states impossible, I don't
> think it really comes down to just use functions either.) What TEA and
> nested TEA provided was architectural guidance on how to structure things
> for long term evolution. Saying, if your update function gets too big you
> can handle individual cases with separate functions is I guess useful advice
> but something that I would hope would be obvious to most people working in a
> functional language. What sort of calling conventions work well? Which ones
> don't work well and should be avoided? That's the sort of architectural
> advice that can be put into practice early on and expect it to pay off later
> 

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

[Mark Hamburg]

The monster model design is one aspect that leads to the ball of mud code.
Let's look at the source quote for the term big ball of mud:

A Big Ball of Mud is a haphazardly structured, sprawling, sloppy,
duct-tape-and-baling-wire, spaghetti-code
 jungle. These systems show
unmistakable signs of unregulated growth, and repeated, expedient repair.
Information is shared promiscuously among distant elements of the system,
often to the point where nearly all the important information becomes
global or duplicated. The overall structure of the system may never have
been well defined. If it was, it may have eroded beyond recognition.
Programmers with a shred of architectural sensibility shun these quagmires.
Only those who are unconcerned about architecture, and, perhaps, are
comfortable with the inertia of the day-to-day chore of patching the holes
in these failing dikes, are content to work on such systems.
— Brian Foote and Joseph Yoder, *Big Ball of Mud.* Fourth Conference on
Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello,
Illinois, September 1997

When everything starts out in one place with access to everything else,
it's natural to end up with everything talking to and depending on
everything else — or at least the dependencies are less likely to be well
regulated because there is no mechanism doing the regulation. Now, as
conservative politicians will love to tell you, regulations get in the way
and we can be more productive without them, so yes, this unregulated
environment is seemingly more productive. The type system will help in
detecting out and out errors in making changes but once things get
intertwined, they become less amenable to significant change. That's often
fine for an agile development model in which one focuses on small changes
but 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. An approach which basically seems to advocate building a monolithic,
intertwined codebase and if that gets to be too much, here are some
techniques to break it down after the fact will work to an extent but will
be fighting to apply order to chaos and almost all the time it will be
easier for a developer trying to get a task done to just add a little more
chaos.

As for your specific advice, it includes several useful points and I've
refactored code using those same techniques, but 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. (I guess it means use functions rather than types but
since types are what allow us to make illegal states impossible, I don't
think it really comes down to just use functions either.) What TEA and
nested TEA provided was architectural guidance on how to structure things
for long term evolution. Saying, if your update function gets too big you
can handle individual cases with separate functions is I guess useful
advice but something that I would hope would be obvious to most people
working in a functional language. What sort of calling conventions work
well? Which ones don't work well and should be avoided? That's the sort of
architectural advice that can be put into practice early on and expect it
to pay off later when changes need to be made. For example, to buttress the
non-component view of the world, one could push on the fact that many views
do not need to own their own state but can simply be functions that render
state provided from somewhere else. One could phrase that as: "You have a
view function but ask yourself whether you really need a model and an
update or whether those are better handled somewhere else. If you do so,
then you can take a big pile of view code and move it somewhere else and
not need to look at it when trying to figure out what is going on in your
model."

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. Mutability v immutability was not a concern here. Of concern
was that question "which parts of this are visible to other code for the
benefit of code within the would be library and which parts are visible
because they are expected to be stable interfaces for other code". And the
fact it was a question arose exactly because the code base started as an
entity that only needed to serve itself and for which the refactorings were
all just adjustments within those bounds. The choices were expedient for
immediate development but detrimental to long-term reuse.

Should one build everything to be reusable/replaceable? Almost certainly
not because doing so does come with overhead. But identifying likely break
points where code may need to be either reused or replaced and structure
those break points up front to enable that reduces the effort when you do
need it 

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

[Yosuke Torii]

Richard,

I'm curious how your product *uses* (not makes) external UI library. 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? I think TEA gives the best user experience for 
those widgets.

If I understand correctly, Marek's library is trying to reduce the cost of 
using them. I agree with your opinion about breaking the monolith or "don't 
make needless things for saving time". It's the best practice of agile 
development. But does "scale" mean just "my app become big"? I expect that 
word to mean "easy to use external library, custom widgets can be easily 
made and they can be used across pages".

I don't think the exploration of TEA is finished. 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.

Terms like "component is proven to be an anti-pattern" sounds too negative 
for me. 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".



2017年4月20日木曜日 2時27分09秒 UTC+9 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]

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

[Mark Hamburg]

Here is where our app is migrating after starting as an intermixture of
view-side code and data-side code.

The high level split is a store and a display. The store knows about things
like how to talk to our server. As I summarized it, the UX code should know
nothing about Phoenix. The display manages the user interaction. Both sides
have state. The store, well, stores information — generally a reflection of
what is on the server or should be on the server. The display, however,
also stores information like whether panels are open, the state of
animations, etc. Just as knowledge of Phoenix doesn't belong in the UX,
knowledge of animations does not belong in the store.

This isn't a radical design by any means. A lot of code is built this way.
It's perhaps more interesting to this discussion to observe that the Elm
community doesn't encourage even this sort of factoring and in fact naive
use of MUV/TEA does lead to a deep intermingling of store and display
concerns. (I guess the "just write one monster model" approach deals with
this by saying that code can choose to only interact with parts of the
model.)

What I've been working through while engineering this split is how to
manage coordination between the two sides.

Sending messages from the display to the store is pretty simple. We've
replaced commands in the update signature with a list of "out messages".
These messages include internal notifications — e.g., canceled, finished,
please shift the target somewhere else, etc — and operations for the world
beyond the display which includes commands to flow out the top of the app,
requests for work by the store, and requests for random number generation
using a shared generator. (This last is much like the effects manager
random logic but it uses the Pcg generator.) The operations are all subject
to command style mapping to adjust the tagging for their responses back to
the display. Notifications are just notifications. The current
implementation involves more boilerplate at every nesting within the
display than I would really like but I'm working on that.

Getting data from the store to the display is more interesting and is an
area I continue to work through.

One naive approach we looked at would be to just hand the store into the
view functions and let them query the store as needed to do their work.
There are two problems with this.

The first is that some display side concepts such as which item is
currently targeted/selected — it's a display-side concept since the server
should never know — need to update in response to store-side changes. For
example, if the selected item goes away, we may want to automatically
select something else. Since we can't do updates during view calls, we need
to provide a way for the display to react to store changes. Our solution
here has been to treat this as one would treat the data if it were entirely
stored on the server: we store a local copy on the display side and perform
a fetch operation to get it from the store. This means that the display
gets to validate its copy and the problem of keeping that copy up to date
is exactly the same as the problem one would have if there were no store
and we were just talking over the wire to a server.(*)

This leads to the second problem: A fetch operation is great for getting
the initial information and replacing commands with operations makes that
pretty easy to implement but how do we keep the data up to date and
relatedly how do we keep track of when the display side loses interest?
Here I'm looking at building a subscription equivalent (an observation?)
but I'm not wild about what it would take to make it efficient in the
presence of say scrolling a grid of several thousand items starting and
stopping observations as the visible items change. But efficiency with
large sets of subscriptions seems like something the Elm implementation
hasn't really worried about either since I think it regenerates and
collects up subscriptions after every mutation — if you adhere to the "no
functions in the model" advice(**), you can't cache your subscriptions
because they hold tagger functions — and has the effects managers diff the
new subscriptions against the old. Maybe things are just efficient enough
as it is but I suspect that it's more likely that with so few effects
managers for Elm, few applications generate large number of subscriptions
at any one time. But lacking any better ideas, we will probably start with
mirroring subscriptions and see whether it blows up the time complexity in
a noticeable way.

Moving on, there's one other bit of code structuring that we've only
recently adopted but which has clarified a lot of code and should help with
writing unit tests. The display side models for the overall experience or
pieces of the experience or particular modal portions of the experience
(e.g, sign in) tend to have a model that hold display specific information
like the state of panels or animations and a logic submodel that holds a

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

[Marek Fajkus]

First of all I have to say I'm really glad we have this discussion. I know 
it's sometimes frustrated to face different opinions but outcome is 
definitely worth it. It looks like we're really not on same page and can 
learn something from other here. Also it seems that groups are good place 
to do that.

I have quite some points to ongoing discussion but I really have no time to 
put them down now since I have to work on things with colleagues.

Anyway since nobody reacted on @peter's comment and I feel it really needs 
to be addressed let me add my opinion just on that for now:

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? 


Creating "components" that  do any kind of HTTP is probably way to hell. 
The only exception are really simple things like let's say jQuery plugins 
or anything which is really really really super isolated.

Generally networking should be on real surface of whole system. There are 
many things that can go wrong. This is the ultimate side-effect since one 
system talking to another over "Maybe Connection" doesn't have any 
guarantees about what that other system does. And you have to assume the 
other system will fail in one way or another. Dealing with failure is 
difficult itself and is hard to do in isolation of system since it pretty 
often has some impact of other things. *Api is the only real "mutable 
object" you have in TEA* (and you can write it in Haskell and do not change 
anything about this fundamental truth)*.* Api is actually global (your 
domain) mutable (even hello word "pure" can return error 500) singleton. 
People with some Erlang experience know costs of fault tolerance. I 
remember in some Evan's comment in Elm's either stdlib or compiler there 
was some note about OTPish (Open Telecom Platform) message passing. Anyway 
even thought Actor model is really great interesting model for concurrency 
it's crucial to understand it leads to some inherited complexity. We surly 
don't want to implement actors in Elm. Rich Hickey (author of Clojure) 
would probably said something like "Adding networking stuff to component is 
completing concerns of how to work with A and how and where to get things A 
needs".

Also getting data is usually not the only thing you need to think of. Say 
you have Blog with posts and you're building admin. There is list of posts 
on left and post detail on right. Now you want to add "delete" function to 
post list so you can click on "delete" button and delete post. The right 
way to do it is emit some action from UI on click (This is what Html.Events 
do for you) and handle it on some very top/surface level - usually update 
but in case of composed updates (like "tea-component") on* the very top one*. 
Why? Because in actions like this you need to really look at system as 
whole. What should happen when user is trying to delete post which is 
actually opened? How can I tell if it's open (probably from route) and so 
on. Only on most top level you can control whole system (even though you 
might use higher lever interfaces of self contain units that if you have 
them).

Of course there are exception but I would rather avoid examples of 
"component that can do http" since this is really where people can hurt 
themselves.

Actually this is precisely why "tea-component" was using that "Action 
Bubbling" and and sending messages to upper component. Component might 
knows how to propagate "delete" action but has no idea about how to proceed 
delete. That is really concern for system as a whole. This is sort of same 
as Html.Events just on higher level. Child just asks "Hey this just 
happened and you might be interested" and system as whole knows how, when 
or if at all to do with it.

This is at least what I thing based on my experience. Hope it makes sense.

On Wednesday, April 19, 2017 at 6:56:23 AM UTC+2, Peter Damoc wrote:
>
> On Wed, Apr 19, 2017 at 2:58 AM, Richard Feldman  > 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

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

[Peter Damoc]

so, the Model-View-Update triplet *is NOT* the wrong unit of composition
for Elm applications? :)

Don't you see how people starting up with Elm could get confused by this
kind of messages?

On Wed, Apr 19, 2017 at 10:03 AM, Richard Feldman <
richard.t.feld...@gmail.com> wrote:

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



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

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

[Peter Damoc]

On Wed, Apr 19, 2017 at 9:19 AM, Richard Feldman <
richard.t.feld...@gmail.com> wrote:

> 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. :)
>
I am genuinely interested in a reasonable answer to the encapsulation of
side-effects components/widgets.
I have tried to think about this when I tried to reimplement the old
tutorial and failed to find a proper solution.
I remember asking about it here (or maybe on Slack) and have no memory of
an answer.

I don't know how to encapsulate the kind of functionality that was
demonstrated in the RandomGif or the SVG Animation with the currently
recommended approach.

It's fine to say, "we don't do it like we used to do it" but there was no
functionally equivalent solution offered.

Also, one could use the old approach to scale by splitting an app into
pages.
I have no idea how to avoid Model-Update-View when implementing the idea of
Pages.

You say:
>
> *we learned that a Model-View-Update triplet is 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?


-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

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

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

[Peter Damoc]

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

[Mark Hamburg]

https://en.m.wikipedia.org/wiki/Big_ball_of_mud

To say, the architectural guidance is to decompose things with functions is
essentially no guidance (architecture) at all since functions are what one
would be building with anyway in a functional language. TEA did outline a
way to build Elm programs. If you discard the nested aspects, then it's
just the API to the program function.

That said, I used the term being also aware of its more positive usage with
regard to LISP.

Mark

On Tue, Apr 18, 2017 at 5:05 PM Nicholas Hollon 
wrote:

> Nobody is advocating for a ball of mud. Richard is describing incremental
> design via refactoring. This is a standard component of agile/extreme
> programming methodologies. I have seen it work. And it can be done using
> modules and functions as your only abstraction tools.
>
> Disagree about what abstractions are the most useful. But throwing around
> the term "ball of mud" is nothing but name-calling.
>
>
> On Tuesday, April 18, 2017 at 3:39:25 PM UTC-7, Rupert Smith wrote:
>>
>> On Tuesday, April 18, 2017 at 9:13:58 PM UTC+1, Mark Hamburg wrote:
>>>
>>> Having read the reddit thread about just starting big and breaking
>>> things down, it reminds of arguments I've heard for years about how
>>> monolithic programs are easier to work with. They are. That's how we end up
>>> with them. It's almost always easier to tack a little more onto an existing
>>> ball of mud. If you've never worked in a statically-typed language then
>>> maybe Elm's type checking seems like a revelation, but it isn't so
>>> revolutionary as to throw out the experience that even static type-checking
>>> only gets you so far. Everything that can change the model can violate the
>>> constraints on the model that fall beyond the capabilities of the type
>>> system. Everything that sees the full model is a potential dependency for
>>> each and every piece of the model. Abstraction barriers are what make big
>>> programs possible. I don't think there is any magic in Elm that changes
>>> this fundamental lesson of 60 years of software development. It may make
>>> you feel you can move the boundaries relative to what some other languages
>>> afford, but if your architecture comes down to saying at the surface we
>>> have these few concepts but inside that we just have a big ball of
>>> type-checked mud, that's not really an architecture.
>>>
>>
>> Well said. I kind of wanted to say something along these lines but you
>> articulated better than I could have. Parnas' modular design principles are
>> my principal guide.
>>
>> There is room for the mud-ball and the pristine encapsulated
>> architecture. I usually do some mud-ball hacking then figure out how I can
>> tidy it up a bit better with a view to encapsulating data models and
>> operations so that they are both well documented and can only be
>> manipulated to produce legal states, as well as how to improve a data model
>> using the type system to eliminate representations of illegal states.
>>
>> Learn both (or all) approaches, I guess. Nested TEA is working very
>> nicely for me and feels appropriate in many situations, but just not as a
>> blanket approach for everything.
>>
>
>
>
>
>
>
>
>
> --
>
>
> 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 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

[Nicholas Hollon]

Nobody is advocating for a ball of mud. Richard is describing incremental 
design via refactoring. This is a standard component of agile/extreme 
programming methodologies. I have seen it work. And it can be done using 
modules and functions as your only abstraction tools.

Disagree about what abstractions are the most useful. But throwing around 
the term "ball of mud" is nothing but name-calling.


On Tuesday, April 18, 2017 at 3:39:25 PM UTC-7, Rupert Smith wrote:
>
> On Tuesday, April 18, 2017 at 9:13:58 PM UTC+1, Mark Hamburg wrote:
>>
>> Having read the reddit thread about just starting big and breaking things 
>> down, it reminds of arguments I've heard for years about how monolithic 
>> programs are easier to work with. They are. That's how we end up with them. 
>> It's almost always easier to tack a little more onto an existing ball of 
>> mud. If you've never worked in a statically-typed language then maybe Elm's 
>> type checking seems like a revelation, but it isn't so revolutionary as to 
>> throw out the experience that even static type-checking only gets you so 
>> far. Everything that can change the model can violate the constraints on 
>> the model that fall beyond the capabilities of the type system. Everything 
>> that sees the full model is a potential dependency for each and every piece 
>> of the model. Abstraction barriers are what make big programs possible. I 
>> don't think there is any magic in Elm that changes this fundamental lesson 
>> of 60 years of software development. It may make you feel you can move the 
>> boundaries relative to what some other languages afford, but if your 
>> architecture comes down to saying at the surface we have these few concepts 
>> but inside that we just have a big ball of type-checked mud, that's not 
>> really an architecture.
>>
>
> Well said. I kind of wanted to say something along these lines but you 
> articulated better than I could have. Parnas' modular design principles are 
> my principal guide.
>
> There is room for the mud-ball and the pristine encapsulated architecture. 
> I usually do some mud-ball hacking then figure out how I can tidy it up a 
> bit better with a view to encapsulating data models and operations so that 
> they are both well documented and can only be manipulated to produce legal 
> states, as well as how to improve a data model using the type system to 
> eliminate representations of illegal states.
>
> Learn both (or all) approaches, I guess. Nested TEA is working very nicely 
> for me and feels appropriate in many situations, but just not as a blanket 
> approach for everything.
>

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

>
> It's certainly reasonable to say that there is a point where pursuing 
> fractal TEA is overkill and not buying one much but extra plumbing work.
>

I would say that pursuing it as the end itself, rather than using it when 
appropriate as the means to an end (the end being a code base that scales 
nicely), is overkill from the start. :)

But it is also exactly the case of things like the sign up form where being 
> able to say "Here is a sign up form. It has a model, messages, update, and 
> view. You embed it in the rest of your app like this."
>

Sure. You can already do that; that is the signup form's API. That doesn't 
imply the checkbox ought to have the same API!
 

> The goal in a composable architecture is to have "like this" fit enough of 
> a pattern that a programmer coming into an embedding situation knows what 
> to expect.
>

That is the purpose of an API; programmers seeking to reuse code know what 
to expect by looking at a clear API.

"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. :)

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

[Mark Hamburg]

If you buy my premise, then one could say that the old examples using
counters were useful because they allowed one to focus on the plumbing
without distraction of use case specific details but problematic because
they also suggested that something the size of the counter model was a good
target to break things down to.

Mark

On Tue, Apr 18, 2017 at 4:44 PM Mark Hamburg  wrote:

> It's certainly reasonable to say that there is a point where pursuing
> fractal TEA is overkill and not buying one much but extra plumbing work.
> But it is also exactly the case of things like the sign up form where being
> able to say "Here is a sign up form. It has a model, messages, update, and
> view. You embed it in the rest of your app like this." The goal in a
> composable architecture is to have "like this" fit enough of a pattern that
> a programmer coming into an embedding situation knows what to expect. TEA
> works pretty well for this though it can feel a bit boilerplate heavy. I
> would put it as:
>
> It's often easiest to work in a monolithic program and there are things
> you can do to mitigate the effects of doing so and thereby build a bigger
> monolith. But when a project gets truly large, the ease of building a
> monolithic ball of mud gives way to the problems of figuring out what
> interacts with what and while the type system will have your back at some
> level, there are limits to what it can achieve. But TEA is fractal. You can
> build more isolated components using the same architecture and embed them
> within your larger program. Do you have multiple pages? It may be natural
> to build each of them using the TEA pattern. You can then fit them together
> in the parent app as follows... The caveat here is that while this is both
> straightforward and robust, it is a noticeable amount of code and
> translation at the glue layer, so taking the TEA hammer and smashing pieces
> down until you have tiny nuggets is going to leave you with a lot of glue
> holding those nuggets together.
>
> Mark
>
> P.S. The checkbox could also have the signature: `checkbox : Bool -> Html
> Bool` and one could use `Html.map` to apply the translation into some other
> message space. I don't know that that's better.
>
>
> On Tue, Apr 18, 2017 at 3:36 PM Richard Feldman <
> richard.t.feld...@gmail.com> wrote:
>
>> Having read the reddit thread about just starting big and breaking things
>>> down, it reminds of arguments I've heard for years about how monolithic
>>> programs are easier to work with.
>>
>>
>> This Reddit post
>> 
>> is about *how to break up a monolith*. It doesn't talk about anything
>> else except how to break up a monolith. :)
>>
>> Abstraction barriers are what make big programs possible. I don't think
>>> there is any magic in Elm that changes this fundamental lesson of 60 years
>>> of software development.
>>
>>
>> I couldn't agree more! Glad we're on the same page about that.
>>
>>
>>> The rest of the world has looked at TEA and seen value in it and is
>>> looking to extend it.
>>
>>
>> If people look at it, see value in it, and then think "okay this works
>> great, but how can we take it in a different direction?" - that sounds like
>> putting the cart before the horse to me.
>>
>> I think a lot of people would be happier if they gave the "use the
>> simplest API that works" approach a shot. :)
>>
>>
>>> The remark that composing TEA-shaped units isn't what Elm is designed
>>> for raises the question of whether we should then be expecting Cmd.map and
>>> friends to be going away since that would seem to be exactly what they are
>>> designed for.
>>>
>>
>> That's a great question! They are designed to make it easier to work with
>> Html and Cmd alongside several message constructors.
>>
>> Example
>>
>> Pretend there is no Html.map and I'm writing a reusable view whose
>> entire API consists of one function:
>>
>> checkbox : (Bool -> msg) -> Bool -> Html msg
>>
>> The only state I care about is whether the checkbox is checked (the Bool
>> argument), and the only user interaction is checking or unchecking the box
>> (the (Bool -> msg) argument; the caller is free to use whatever Msg type
>> they are already working with, no conversion necessary).
>>
>> Using a higher-order function to manage messages is a great lightweight
>> default choice, so I don't miss Html.map at all here. I wouldn't use it
>> regardless!
>>
>> Now let's say what I'm building is not a reusable checkbox, but something
>> more complex: a reusable *signup form* that expands in-place when the
>> user clicks it.
>>
>> This will involve a lot more Msg constructors - for recording text entry
>> in the username/password fields, HTTP responses for username availability
>> checks, expanding and collapsing it, submitting it...overall, a lot more
>> going on. Let's say it needs 10 message constructors to work properly.
>>
>> Using the same API design as 

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

[Mark Hamburg]

It's certainly reasonable to say that there is a point where pursuing
fractal TEA is overkill and not buying one much but extra plumbing work.
But it is also exactly the case of things like the sign up form where being
able to say "Here is a sign up form. It has a model, messages, update, and
view. You embed it in the rest of your app like this." The goal in a
composable architecture is to have "like this" fit enough of a pattern that
a programmer coming into an embedding situation knows what to expect. TEA
works pretty well for this though it can feel a bit boilerplate heavy. I
would put it as:

It's often easiest to work in a monolithic program and there are things you
can do to mitigate the effects of doing so and thereby build a bigger
monolith. But when a project gets truly large, the ease of building a
monolithic ball of mud gives way to the problems of figuring out what
interacts with what and while the type system will have your back at some
level, there are limits to what it can achieve. But TEA is fractal. You can
build more isolated components using the same architecture and embed them
within your larger program. Do you have multiple pages? It may be natural
to build each of them using the TEA pattern. You can then fit them together
in the parent app as follows... The caveat here is that while this is both
straightforward and robust, it is a noticeable amount of code and
translation at the glue layer, so taking the TEA hammer and smashing pieces
down until you have tiny nuggets is going to leave you with a lot of glue
holding those nuggets together.

Mark

P.S. The checkbox could also have the signature: `checkbox : Bool -> Html
Bool` and one could use `Html.map` to apply the translation into some other
message space. I don't know that that's better.


On Tue, Apr 18, 2017 at 3:36 PM Richard Feldman 
wrote:

> Having read the reddit thread about just starting big and breaking things
>> down, it reminds of arguments I've heard for years about how monolithic
>> programs are easier to work with.
>
>
> This Reddit post
> 
> is about *how to break up a monolith*. It doesn't talk about anything
> else except how to break up a monolith. :)
>
> Abstraction barriers are what make big programs possible. I don't think
>> there is any magic in Elm that changes this fundamental lesson of 60 years
>> of software development.
>
>
> I couldn't agree more! Glad we're on the same page about that.
>
>
>> The rest of the world has looked at TEA and seen value in it and is
>> looking to extend it.
>
>
> If people look at it, see value in it, and then think "okay this works
> great, but how can we take it in a different direction?" - that sounds like
> putting the cart before the horse to me.
>
> I think a lot of people would be happier if they gave the "use the
> simplest API that works" approach a shot. :)
>
>
>> The remark that composing TEA-shaped units isn't what Elm is designed for
>> raises the question of whether we should then be expecting Cmd.map and
>> friends to be going away since that would seem to be exactly what they are
>> designed for.
>>
>
> That's a great question! They are designed to make it easier to work with
> Html and Cmd alongside several message constructors.
>
> Example
>
> Pretend there is no Html.map and I'm writing a reusable view whose entire
> API consists of one function:
>
> checkbox : (Bool -> msg) -> Bool -> Html msg
>
> The only state I care about is whether the checkbox is checked (the Bool
> argument), and the only user interaction is checking or unchecking the box
> (the (Bool -> msg) argument; the caller is free to use whatever Msg type
> they are already working with, no conversion necessary).
>
> Using a higher-order function to manage messages is a great lightweight
> default choice, so I don't miss Html.map at all here. I wouldn't use it
> regardless!
>
> Now let's say what I'm building is not a reusable checkbox, but something
> more complex: a reusable *signup form* that expands in-place when the
> user clicks it.
>
> This will involve a lot more Msg constructors - for recording text entry
> in the username/password fields, HTTP responses for username availability
> checks, expanding and collapsing it, submitting it...overall, a lot more
> going on. Let's say it needs 10 message constructors to work properly.
>
> Using the same API design as we did for checkbox above, we'd write
> something like this:
>
> signupForm : (SignupForm.State -> GiganticRecordOfTenMsgConstructors msg)
> -> SignupForm.State -> Html msg
>
> With this API, reusing this signup form entails spelling out all 10 Msg
> constructors as the first argument to this function. That's a lot more work
> than the single Bool argument needed by checkbox! This is where a more
> heavyweight approach can pay off: creating a new SignupForm.Msg and
> having signupForm return Html SignupForm.Msg instead of Html msg.
>
> 

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

['Rupert Smith' via Elm Discuss]

On Tuesday, April 18, 2017 at 9:13:58 PM UTC+1, Mark Hamburg wrote:
>
> Having read the reddit thread about just starting big and breaking things 
> down, it reminds of arguments I've heard for years about how monolithic 
> programs are easier to work with. They are. That's how we end up with them. 
> It's almost always easier to tack a little more onto an existing ball of 
> mud. If you've never worked in a statically-typed language then maybe Elm's 
> type checking seems like a revelation, but it isn't so revolutionary as to 
> throw out the experience that even static type-checking only gets you so 
> far. Everything that can change the model can violate the constraints on 
> the model that fall beyond the capabilities of the type system. Everything 
> that sees the full model is a potential dependency for each and every piece 
> of the model. Abstraction barriers are what make big programs possible. I 
> don't think there is any magic in Elm that changes this fundamental lesson 
> of 60 years of software development. It may make you feel you can move the 
> boundaries relative to what some other languages afford, but if your 
> architecture comes down to saying at the surface we have these few concepts 
> but inside that we just have a big ball of type-checked mud, that's not 
> really an architecture.
>

Well said. I kind of wanted to say something along these lines but you 
articulated better than I could have. Parnas' modular design principles are 
my principal guide.

There is room for the mud-ball and the pristine encapsulated architecture. 
I usually do some mud-ball hacking then figure out how I can tidy it up a 
bit better with a view to encapsulating data models and operations so that 
they are both well documented and can only be manipulated to produce legal 
states, as well as how to improve a data model using the type system to 
eliminate representations of illegal states.

Learn both (or all) approaches, I guess. Nested TEA is working very nicely 
for me and feels appropriate in many situations, but just not as a blanket 
approach for everything.

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

>
> Having read the reddit thread about just starting big and breaking things 
> down, it reminds of arguments I've heard for years about how monolithic 
> programs are easier to work with.

 
This Reddit post 

 
is about *how to break up a monolith*. It doesn't talk about anything else 
except how to break up a monolith. :)

Abstraction barriers are what make big programs possible. I don't think 
> there is any magic in Elm that changes this fundamental lesson of 60 years 
> of software development.


I couldn't agree more! Glad we're on the same page about that.
 

> The rest of the world has looked at TEA and seen value in it and is 
> looking to extend it.


If people look at it, see value in it, and then think "okay this works 
great, but how can we take it in a different direction?" - that sounds like 
putting the cart before the horse to me.

I think a lot of people would be happier if they gave the "use the simplest 
API that works" approach a shot. :)
 

> The remark that composing TEA-shaped units isn't what Elm is designed for 
> raises the question of whether we should then be expecting Cmd.map and 
> friends to be going away since that would seem to be exactly what they are 
> designed for.
>

That's a great question! They are designed to make it easier to work with 
Html and Cmd alongside several message constructors.

Example

Pretend there is no Html.map and I'm writing a reusable view whose entire 
API consists of one function:

checkbox : (Bool -> msg) -> Bool -> Html msg

The only state I care about is whether the checkbox is checked (the Bool 
argument), and the only user interaction is checking or unchecking the box 
(the (Bool -> msg) argument; the caller is free to use whatever Msg type 
they are already working with, no conversion necessary).

Using a higher-order function to manage messages is a great lightweight 
default choice, so I don't miss Html.map at all here. I wouldn't use it 
regardless!

Now let's say what I'm building is not a reusable checkbox, but something 
more complex: a reusable *signup form* that expands in-place when the user 
clicks it.

This will involve a lot more Msg constructors - for recording text entry in 
the username/password fields, HTTP responses for username availability 
checks, expanding and collapsing it, submitting it...overall, a lot more 
going on. Let's say it needs 10 message constructors to work properly.

Using the same API design as we did for checkbox above, we'd write 
something like this:

signupForm : (SignupForm.State -> GiganticRecordOfTenMsgConstructors msg) 
-> SignupForm.State -> Html msg

With this API, reusing this signup form entails spelling out all 10 Msg 
constructors as the first argument to this function. That's a lot more work 
than the single Bool argument needed by checkbox! This is where a more 
heavyweight approach can pay off: creating a new SignupForm.Msg and having 
signupForm return Html SignupForm.Msg instead of Html msg.

Here's how that API would look:

signupForm : SignupForm.State -> Html SignupForm.Msg

type SignupForm.Msg

We had to do more work to set this up, of course (the checkbox function 
didn't need the Msg implementation this signupForm function requires), but 
we successfully eliminated the need for the gigantic record argument. Great!

In exchange, though, not only have we needed a new Msg type on the 
SignupForm side, but now we also need our caller to convert from 
SignupForm.Msg to whatever their local flavor of Msg is. (Hence why this is 
a more heavyweight approach.)

Since our application uses FooApp.Msg, but signupForm returns Html 
parameterized 
on a SignupForm.Msg, we'll have a type mismatch if our application's view 
tries to call signupForm directly. In the absence of Html.map, we're stuck 
- this thing is no longer reusable, it's become a nonfunctional art piece 
that we can't actually plug in anywhere.

If we have Html.map, problem solved! We can add this approach to our 
toolbox, right alongside the simpler "one higher-order function and you're 
done" API we used for checkbox.

Overengineering

Now granted, Html.map does introduce the potential for overengineering. We 
wrote this earlier:

checkbox : (Bool -> msg) -> Bool -> Html msg

This was an unremarkably simple API, but Html.map gives us the ability to 
replace this single function with a full-blown Checkbox module, complete 
with:

   - type alias Model = { checked : Bool }
   - type Msg = SetChecked Bool
   - update : Msg -> Model -> ( Model, Cmd Msg) *[gotta return Cmd Msg in 
   addition to Model, because what if someday our checkbox wants to send HTTP 
   requests?!]*
   - view : Model -> Html Msg
   - a chauffeured Rolls-Royce to deliver the single Boolean worth of state 
   and interaction from one function to another.

To implement this massively overengineered API (remember, we achieved the 
same functionality using *one

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

[Mark Hamburg]

The remark that composing TEA-shaped units isn't what Elm is designed for
raises the question of whether we should then be expecting Cmd.map and
friends to be going away since that would seem to be exactly what they are
designed for.

Having read the reddit thread about just starting big and breaking things
down, it reminds of arguments I've heard for years about how monolithic
programs are easier to work with. They are. That's how we end up with them.
It's almost always easier to tack a little more onto an existing ball of
mud. If you've never worked in a statically-typed language then maybe Elm's
type checking seems like a revelation, but it isn't so revolutionary as to
throw out the experience that even static type-checking only gets you so
far. Everything that can change the model can violate the constraints on
the model that fall beyond the capabilities of the type system. Everything
that sees the full model is a potential dependency for each and every piece
of the model. Abstraction barriers are what make big programs possible. I
don't think there is any magic in Elm that changes this fundamental lesson
of 60 years of software development. It may make you feel you can move the
boundaries relative to what some other languages afford, but if your
architecture comes down to saying at the surface we have these few concepts
but inside that we just have a big ball of type-checked mud, that's not
really an architecture.

The rest of the world has looked st TEA and seen value in it and is looking
to extend it. It's sad to see Elm itself — which really is a nice language
— potentially treating it as little more than a veneer. I welcome efforts
like Marek's to try to figure out how to build something other than a ball
of mud with Elm.

Mark

On Tue, Apr 18, 2017 at 10:04 AM Richard Feldman <
richard.t.feld...@gmail.com> wrote:

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

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

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

[Marek Fajkus]

*reposting due to nonsense in code example - Can't write without Emacs, 
sorry:(*

I really feel you get the whole idea, brilliant!

I don't really know what I should add to that but at first - *Package was 
taken down on my own request.* At this point I agree that term component 
even though it might make sense from some point of view isn't really the 
best choice. Also in elm-dev I have described our use-case briefly which I 
believe makes it clear why I some people might want to structure app in 
terms of Parent-Child modules.

I would also question the use of the term "polymorphic" to describe the 
> more generalized


100% agree. I'm not happy with that name either.

I think that using commands to send messages to parents is probably a 
> dangerous choice 


In most cases this is useful for async actions anyway (like component 
requesting data parent knows how to get for instance). Sometimes you don't 
know who and if anyone is interested that you (bottom update) did 
something. Good example might be
 http://package.elm-lang.org/packages/zaboco/elm-draggable/latest 
 which is 
also sending Cmd.

If you need anything else just expose Msg with constructors (Msg(..)) from 
children. That way you can pattern match on children's Msg in parent like:


update msg model =
   case msg of
  ChildMsg childMsg ->
  let
  newModel =
  if childMsg == Child.Msg.Important then
  { model | itHappend = True }
  else
  model
  in
  (newModel, Cmd.none)
  |> Component.update child childMsg


(hope that code is clear)

Anyway there are some questions how to do some things for sure. I'm really 
happy someone have look at it and was able to understand it that well. 
Appreciated.


On Tuesday, April 18, 2017 at 5:39:16 PM UTC+2, Mark Hamburg wrote:
>
> Marek Fajkus's original announcement was on elm-dev but that list tends to 
> become disapproving of discussions fast, so I'm moving over to here to 
> discuss it. The post suggested that it was in the Elm package library but 
> it seems to have been pulled, so I will point to the Github repository:
>
> https://github.com/turboMaCk/tea-component
>
> I've read the ReadMe but haven't looked at the code or the examples beyond 
> the ReadMe.
>
> Two things immmediately struck me:
>
> 1. It seems like an interesting idea to wrap the embedding up into a 
> single structure. It doesn't really reduce the boilerplate that much but it 
> makes it seem simpler because it isn't spread out and the number of type 
> annotations needed is smaller. I see it as a more elaborate form of lenses 
> — a structure I've started pushing through my code to consolidate various 
> idioms (and to reduce copy-paste-change errors when I've got multiple 
> record fields of the same type and hence the type system won't help me when 
> I miss a change).
>
> 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. The 
> examples focused on things like going from one counter to multiple 
> counters. This carried over into Elm 0.17 where Cmd.map and Sub.map were 
> clearly targeted at this sort of composition and Html.map both helped with 
> the composition and with making Html.Lazy work in an environment with 
> composition.(*) 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. This ignores the fact that in many cases, 
> the units can't be encapsulated into single functions. On the other hand, 
> the accompanying piece with these functions is generally Config arguments 
> and what this package does is provide a useful standard Config and 
> functions to work with that Config when embedding.
>
> Turning back to the package in question, I would also question the use of 
> the term "polymorphic" to describe the more generalized case in that the 
> thing it describes can't really be used in multiple contexts as presented. 
> Still, it's good to show that the pattern fits with variations on 
> TEA-shaped units.
>
> Finally, while it was also interesting to see the material on action 
> bubbling, I think that using commands to send messages to parents is 
> probably a dangerous choice since there are few if any guarantees regarding 
> delivery order. Our solution has been to replace commands with out messages 
> that subsume commands as one special case. This has given us a lot of 
> flexibility to handle notifications — e.g., the login component can report 
> back to the parent on login success, a modal process can report if 
> canceled, etc — but it does involve more boilerplate. I may

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

[Marek Fajkus]

I really feel you get the whole idea, brilliant!

I don't really know what I should add to that but at first - *Package was 
taken down on my own request.* At this point I agree that term component 
even though it might make sense from some point of view isn't really the 
best choice. Also in elm-dev I have described our use-case briefly which I 
believe makes it clear why I some people might want to structure app in 
terms of Parent-Child modules.

I would also question the use of the term "polymorphic" to describe the 
> more generalized


100% agree. I'm not happy with that name either.

I think that using commands to send messages to parents is probably a 
> dangerous choice 


In most cases this is useful for async actions anyway (like component 
requesting data parent knows how to get for instance). Sometimes you don't 
know who and if anyone is interested that you (bottom update) did 
something. Good example might be
 http://package.elm-lang.org/packages/zaboco/elm-draggable/latest 
 which is 
also sending Cmd.

If you need anything else just expose Msg with constructors (Msg(..)) from 
children. That way you can pattern match on children's Msg in parent like:

update msg model =
   case msg of
  let
 newModel =
   ChildMsg childMsg =
  if childMsg == Child.Msg.Magic then
 { model | itHappened = True }
  else
model
   in
  (newModel, Cmd.none)
 |> Component.update child childMsg

(hope that code is clear)

Anyway there are some questions how to do some things for sure. I'm really 
happy someone have look at it and was able to understand it that well. 
Appreciated.

On Tuesday, April 18, 2017 at 5:39:16 PM UTC+2, Mark Hamburg wrote:
>
> Marek Fajkus's original announcement was on elm-dev but that list tends to 
> become disapproving of discussions fast, so I'm moving over to here to 
> discuss it. The post suggested that it was in the Elm package library but 
> it seems to have been pulled, so I will point to the Github repository:
>
> https://github.com/turboMaCk/tea-component
>
> I've read the ReadMe but haven't looked at the code or the examples beyond 
> the ReadMe.
>
> Two things immmediately struck me:
>
> 1. It seems like an interesting idea to wrap the embedding up into a 
> single structure. It doesn't really reduce the boilerplate that much but it 
> makes it seem simpler because it isn't spread out and the number of type 
> annotations needed is smaller. I see it as a more elaborate form of lenses 
> — a structure I've started pushing through my code to consolidate various 
> idioms (and to reduce copy-paste-change errors when I've got multiple 
> record fields of the same type and hence the type system won't help me when 
> I miss a change).
>
> 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. The 
> examples focused on things like going from one counter to multiple 
> counters. This carried over into Elm 0.17 where Cmd.map and Sub.map were 
> clearly targeted at this sort of composition and Html.map both helped with 
> the composition and with making Html.Lazy work in an environment with 
> composition.(*) 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. This ignores the fact that in many cases, 
> the units can't be encapsulated into single functions. On the other hand, 
> the accompanying piece with these functions is generally Config arguments 
> and what this package does is provide a useful standard Config and 
> functions to work with that Config when embedding.
>
> Turning back to the package in question, I would also question the use of 
> the term "polymorphic" to describe the more generalized case in that the 
> thing it describes can't really be used in multiple contexts as presented. 
> Still, it's good to show that the pattern fits with variations on 
> TEA-shaped units.
>
> Finally, while it was also interesting to see the material on action 
> bubbling, I think that using commands to send messages to parents is 
> probably a dangerous choice since there are few if any guarantees regarding 
> delivery order. Our solution has been to replace commands with out messages 
> that subsume commands as one special case. This has given us a lot of 
> flexibility to handle notifications — e.g., the login component can report 
> back to the parent on login success, a modal process can report if 
> canceled, etc — but it does involve more boilerplate. I may see whether I 
> can adapt Marek's approach to this more general embedding mechanism.
>
> In any event, I recomm