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 <input> 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 > <https://groups.google.com/d/msg/elm-discuss/Lo6bG96zotI/0ak6T2DaDgAJ> > 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 > > <https://www.reddit.com/r/elm/comments/5jd2xn/how_to_structure_elm_with_multiple_models/dbkpgbd/> > ." > 2. Later > <https://groups.google.com/d/msg/elm-discuss/Lo6bG96zotI/-GOgsoHsDgAJ> > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
