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. https://github.com/rupertlssmith/wood-polymer 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
