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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

> > Sorry again for confusing. > It's all good! :) You were super polite and respectful throughout. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

so, the Model-View-Update triplet *is NOT* the wrong unit of composition for Elm applications? :) 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

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

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

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

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

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

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

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

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

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

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

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

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

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

*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

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

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