Needing to set state on a component feels like an anti-pattern.

I did however became aware of a big limitation to this approach: ports.

ports seam to be needed in order to implement triggering events in order to
communicate with the outside of the component.

This limits the usefulness of the method because it bans the components
from package.elm-lang.org.

what do you think about this?



On Wed, Oct 12, 2016 at 3:34 PM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

>
>
> On Tuesday, October 11, 2016 at 11:07:46 AM UTC+1, Rupert Smith wrote:
>>
>> On Monday, October 10, 2016 at 10:40:25 PM UTC+1, Peter Damoc wrote:
>>>
>>> Now, the next challenge is to figure a way to declare all this in Elm
>>> and automate as much as possible the process of creating the custom
>>> components. :)
>>>
>>
>> I think rolling these Elm web components by hand should continue for a
>> while until issues are ironed out and the pattern becomes well established.
>>
>
> So there is an issue with being able to change the state of the component,
> post initialization, from the consumer of the component. Because if there
> is a port used to set state on the component... which component?
>
> We set the port up for setting its value like this:
>
> app.ports.setCount.subscribe(count => {
>     this.count = count;
> });
>
> I exposed this port in my API module, so the user of the component could
> call it:
>
> port module API exposing (counter, initialCount, onCountChanged, setCount)
> ...
>
> port setCount : Int -> Cmd msg
>
> Calling setCount from within the components program works, but calling it
> from within the consumers program? It does not have a way to know which
> component to 'setCount' on, if there was >1 of them on the screen.
>
> I'll try it.
>
> But this means that there is a limitation on what I can do with
> webcomponents so far:
>
> Can initialize state using attributes on the component, by
> serlizing/deserializing init data in and out of Elm.
> Can trigger events on the Component and on the Consumer.
> Cannot make a call from the consumer to set state on the component
> dynamically.
>
> Perhaps this limitation is even useful as it will tend to lead to
> component designs that are declarative as they have to be built up front
> and live independently after that.
>
> I can also see some evil way of doing this... also passing an id down the
> port, then using it on the other end to figure out which component to
> 'invoke the port' on. I suppose you could even pass javascript as a string
> down a port and run it on the other end so there are definitely going to be
> ways of overcoming limitations.
>
> --
> 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.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
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