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 
necessitate more ports and more javascript.

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. 
paper has a lot of javascript in it, but its well tested and designed and 
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 - 
although it does add to the overhead by pulling in more Polymer javascript. 
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 
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