On Thursday, October 13, 2016 at 9:33:18 AM UTC+1, Rupert Smith wrote: > > On Wednesday, October 12, 2016 at 5:34:36 PM UTC+1, Peter Damoc wrote: >> >> On Wed, Oct 12, 2016 at 6:57 PM, 'Rupert Smith' via Elm Discuss < >> [email protected]> wrote: >> >>> This limitation means you can't have UI elements defined outside of a >>> component affect its state. Suppose you had a video component and a video >>> control bar compnent, you could not make those separate components, you'd >>> always have to embed the control bar inside the video component. >>> >> >> To my understanding, Html elements are treated as stateless so, there is >> no semantic to tell a certain Html element anything just like you cannot >> tell the integer number 42 to do something. It's just data. It's not an >> object. >> >> If someone wants to say something to the actual html element, they have >> to give that element an ID in Elm and go to JS in order to give it a >> message. >> > > Right, that is good point. State must always go on the model. > > Sticking with my video controller analogy - suppose we put the "pause : > Bool" on the model, then the onClick action can simply set the state there. > Perhaps you could define a record visible in the components API, that holds > all of its state that can be modified from the outside. I wonder what > happens though, when the video component is re-built from this model: > > type alias Model = > { ... > , vidState : Video.Model > } > > video model.vidstate [ src "http://myvids.com/cute_cats.mpg > <http://www.google.com/url?q=http%3A%2F%2Fmyvids.com%2Fcute_cats.mpg&sa=D&sntz=1&usg=AFQjCNGiW_qrqfzOjZaj4nXSwqtxzPhI2w>" > > ] > [ videoControl [] [ button [ onclick Pause ] [ text "pause" ] ] ] > > Presumably the change to the state would cause a brand new video control > to be rendered and lose internal state like which point in the video you > were currently watching? > > Still, I quite like the idea of making any externally accesible state an > explicit type in the Elm program, even if the above approach were combined > with a ComponentId and a helper function using a port to set state on the > component; at least from the point of view of the Elm program we are > keeping state in the model not the Html component. >
Any updates to the components state could be handled by a single helper function, which is quite convenient: updateComponent : ComponentId -> Model -> Cmd msg or perhaps you always put the ComponentId in the Model so it is just updateComponent : Model -> Cmd msg -- 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.
