On Sunday, August 28, 2016 at 10:14:43 AM UTC+2, Richard Feldman 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 >
Oh dear.. Given this was supposed to be a summary of what I understood from your reply to a question I had about extensible records, it's rather embarrassing for me! Looks like I'm not on the path to enlightenment after all! Still, I think the idea was worth sharing so I'll clarify. By "component" I mean any elm module you wish to use in several applications. The elm architecture tutorials covers two extreme cases: (1) the application has completely independent components (eg. two independent counter widgets) (2) all parts of the application share the same state If I take the example of a clock widget (time picker) used in several places of an application, it has both an external state (the time) and an internal state (eg. which part of the widget is hovered) that the rest of the application neither knows nor cares about. All I'm saying is that the clock's update should only make changes to the internal state & not change external state which will be updated by passing a (Date -> msg) function to the clock's view: it almost seems as if, in Elm, you delegate upwards... In the case of the server requests, I'm simply suggesting to give each "update" function an extra (Request -> msg) parameter so that the ordering of the request & actual execution is done at a single place in the application higher up where more context is available. I think using all of Msg+update+view+Model in a component is not always necessary & maybe the elm architecture tutorial could have an extra example or two with, eg. a date picker to illustrate the case where you have reusable parts that maintain a private state & use a shared state. > > That's totally on me, but I'm quickly becoming convinced that Evan's view > of the term "components" > <https://www.reddit.com/r/elm/comments/4xsqhd/practical_examples_in_elm/> > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
