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 <
>> elm-d...@googlegroups.com> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to