On Monday, October 17, 2016 at 10:29:52 AM UTC+1, Rupert Smith wrote:
> On Friday, October 14, 2016 at 2:50:44 PM UTC+1, Peter Damoc wrote:
>> On Fri, Oct 14, 2016 at 1:35 PM, 'Rupert Smith' via Elm Discuss <
>> elm-d...@googlegroups.com> wrote:
>>> 1. Build some support into the Elm compiler for webcomponents.
>> There could also be a direction where Elm compiler only implements
>> support for Custom Elements.
>> It would be awesome if someone more knowledgeble in JS could research
>> what is the minimal amount of change needed to support that in a nice way.
>> Ideally, it would be some library that would allow the implementation of
>> the custom elements without ports or need for extra JS so that custom
>> elements could be implemented and shared through the official package
>> This could simplify a lot of things, if taken in a 5 years perspective
>> where Elm has even better tools take advantage of all the extra information
>> that the language brings in order to create highly efficient deliverables.
> The thing is... custom elements are only part of what makes a component.
> Indeed in Elm, you don't even really need custom components, since you are
> not working in Html directly but writing functions to generate Html. For
> example, from the elm-mdl library I can do "Card.view ..." to add a card
> component to my UI. Already the limited pallete of Html has been overcome
> by a library of functions.
> The ports are used to receive updates or to set state on the component. In
> a modular sense, a component encapsulates some state and provides a set of
> 'methods' to read and write that state in a carefully controlled manner,
> with the intention of providing a nice abstraction for working with a
> component, that cannot be put into an illegal state by reading or writing
> private state.
> So in terms of compiler/langauge support that is what is missing - a way
> for one Elm program to include another as a module, but to only be able to
> access that module through a restricted set of events and writeable state.
> It is Parnas principles of modular design really.
Looking at this elm meetup presentation on elm-mdl:
elm-mdl had similar consideration about private state and private update
events that are not really meant to be exposed to the consumer of it. The
presentation shows how this could be done within the TEA framework, all it
requires from the consumer is that they include the Mdl model in their
model, and hook up to an Mdl event to pass along internal events.
I suspect this approach might be more appealing for Elm than the more OO
apporach to modularisation that I describe above. webcomponents written
this way, would not have their own main Program though, so could not stand
alone as components outside of an Elm consumer.
You received this message because you are subscribed to the Google Groups "Elm
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.