I think the problem is that "components" in other communities tends to mean "reusable components" and while reuse is certainly valuable, what is of more concern is how to subdivide and partition state/logic/functionality etc and how to do so in a sufficiently general pattern that people don't need to figure everything out with each new program they look at. For example, view functions are a simple concept and they compose well. If we have one piece nested inside the other, the outer view function will call the inner view function. If the type of the inner piece is known, it can do so directly. If it's handled in a type parameter, then the inner view function needs to be supplied as a parameter. TEA also provides a standard pattern for building update functions though that tends to be more complicated than view functions because of information propagation between pieces. We are also now seeing advisory patterns like "don't store state in more than one place and here is how to avoid doing so". So, maybe components sound too much like objects and should be avoided but what are needed are patterns of partitioning and coordination.
Mark P.S. We also need performance-oriented patterns. For example, I'm concerned that a complex model — regardless of how it is partitioned or not — could require many subscriptions and if these are re-computed and effects managers are updated on every change to the model, there is likely to be a lot of repeated busy work. Are there patterns for managing subscriptions that avoid that? On Aug 28, 2016, at 1:14 AM, Richard Feldman <[email protected]> wrote: >> Components should only update their own private non-shared state that other >> components don't need. Shared states such as your server queue are updated >> at the highest level and each sub component merely receives a function to >> run the update. > > Apologies, but I have read and re-read this and I'm still not sure what it's > saying. :x > > That's totally on me, but I'm quickly becoming convinced that Evan's view of > the term "components" is dead-on: our speaking in terms of "components" seems > to result in way more confusion than positive outcomes. I'm on board with the > idea that we should stop using it to describe portions of Elm programs, and > instead focus discussions on terms whose definitions are clearly applicable: > modules, functions, data, and the first-class Elm Architecture building > blocks of Model, Msg, update, and view. > > I gather that this is has to do with an interaction between two update > functions...is there some way to rephrase it in terms of how those two update > functions interact? > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
