On Tuesday, October 11, 2016 at 11:21:05 AM UTC+1, Rupert Smith wrote:
> I'm interested in expanding on the counter example to add more complexity
> - and I have a component in mind that will be useful to me - the listbox
> that I was working with previously.
> The areas to add more complexity to are:
> More complex data on initialization - for example, passing a list of items
> to init the list box with. This will be a List (String, String) in the Elm
> application -> json array of string, string -> List (String, String) in the
> Elm component. That is, just needs encoder/decoder written to handle it.
> More complex data on update - same as above really, provide a list of
> selected items every time it changes.
> More complex internal state on the component - more options on the
> component for things like max items to display before adding a scroll bar,
> the scroll bar and scroll state itself. Ability to fetch the list of items
> from the server, so I can configure a listbox like this <elm-listbox
> href="http:/.../picklists/somelist">, and have the component manage the
> request/response lifecycle itself.
I've pushed an update to the listbox to display an elm-mdl checkbox when
items in the list are selected. It works nicely and I will re-use it many
time accross my code.
Scroll bars and multi-select/single-select are things that I may continue
to add. I won't add the ability for it to fetch its contents through a REST
API call, as that would be too restrictive, that will remain the
responsibility of the consumer of the component.
Other than that, I am going to pause on this elm+polymer exploration for a
while, or until I feel the need to create some new and wonderful component
that I have a pressing need for.
I think elm+polymer could be taken in a number of directions:
1. Build some support into the Elm compiler for webcomponents. This would
be a new 'program' type with support for hooking parts of the program state
and events up to a webcomponent. The consuming program would also be able
to link to it, in such a way that it can be given access to its 'public'
state. This is really OO encapsulation, and as such might not be a popular
idea within Elm. I only have a vague idea of what tighter integration would
look like anyway, so far too early to start down this route.
2. Build a component library using Elm + minimal amount of Polymer.
Overcoming restrictions previously discussed is generally going to
3. Build components on top of polymer-paper elements in the MDL style.
elm-mdl is ideal for this as both it and paper are built with MDL in mind.
all useful. Many components built on top of it would just be Elm window
dressing - to expose selected events on the component to the consumer. Some
more sophisticated components could be built with more behaviour defined in
Elm and so long as these work in a mostly declarative fashion, not
requiring too much sharing of state between the consumer and the component,
some nice stuff could be built.
Having explored this in some depth I think 3 would be the way to do -
The reasons I say 3 are: already proved that Elm can work with Polymer
nicely without needing to be changed, there is already something well
tested and fairly comprehensive to build on top of, it is the direction in
which progress could be made fastest, it requires the least 'native' code
and number of ports to be workable.
If anyone is up for working up some more Polymer+Elm components, I'm up for
joining in the effort.
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.