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.

[elm-discuss] Re: Structuring model and messages | Debouncing in a large app

[Simon]

THANKS SO MUCH!

I don't know that whether its true that effects modules can't be published 
on elm-package - this one at least has no native code which I know to be a 
blocker.

But as we both noted, there are times when the TEA does not, and arguably 
cannot, provide a good developer experience. It is such a shame that 
effects modules are so frowned upon.




On Thursday, 20 April 2017 22:00:50 UTC+2, jsch...@pivotal.io wrote:
>
> My comment is RE debouncing in particular.  I too have been frustrated to 
> see so many debouncing libraries.  The problem is that none of them are 
> great, because debouncing makes the most sense to solve as a managed 
> effect, rather than in user-space.  And, effect packages can't be published 
> afaik.  There are quite a few of this type out there on github.  The one 
> that we use to good effect is here: 
> https://github.com/tracker-common/elm-debouncer/blob/be3bd02ccac6b71b0088c08359b3f45b5ae7c4dc/src/Debouncer.elm
>  
> (sorry for the outstanding PR).  It provides an api very similar to 
> Task.attempt, but the task given to it will be debounced.  There are 
> similar ones that deal with Msg instead of tasks (
> https://github.com/unbounce/elm-debounce), but I like to keep my effects 
> in tasks as long as possible so I can chain/map them as needed before 
> sending them out.
>
> On Thursday, April 20, 2017 at 3:18:28 AM UTC-6, Simon wrote:
>>
>> First of all - 6 debouncing libraries! Would be great to see elm-package 
>> be able to surface github stars directly (or some other means of identify 
>> the most-likely-to-be-good library)
>>
>> My question though is the following. The type signature of a debounce 
>> state is DebounceState Msg. I.e. it needs the message type as that’s 
>> what it is going to send back later.
>>
>> But in a large app, I usually have the model in 1 file and import that 
>> into my update/view files and it is in the latter that I define the type 
>> Msg.
>>
>> I’m quickly going to get a singularity if I try to import my Msgs into 
>> my model.
>>
>> I’ve never separated out my Msgs before into a separate file but can see 
>> some other benefits. But there will also be costs too.
>>
>> So I was wondering 
>>
>>- what other experiences people had had with separating out Msgs 
>>- whether there was an alternative to this to handle the issue at 
>>hand - debouncing (all of the examples in the libraries are tiny single 
>>file ones inevitably) 
>>
>> ​
>>
>

-- 
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: ANN: TypedSvg

['Rupert Smith' via Elm Discuss]

On Thursday, April 20, 2017 at 12:33:54 PM UTC+1, Jakub Hampl wrote:
>
> https://codepen.io/anon/pen/gWrbxr
>

Very nice. And I see your point - you have multiple strings within a single 
 node. Perhaps my suggestion of a help function that takes a single 
String is not so useful.

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