Roadmap

[debois]

[Continuing discussion from #253.]

Google won't continue development on MDL, recommending instead a switch to MDC (can someone furnish a link corroborating this statement?)

This leaves the following challenges for elm-mdl:

1. Short-term, elm-mdl needs textfield with autocomplete and textfield with dropdown. Since these are not going to come from Google, I suppose we make some ourselves. Does anyone want to take a first stab at either? (It might be possible to repurpose code from Menu.) I'd be very happy to assist from the sidelines.

2. Long-term, where does elm-mdl go in the absence of MDL v2? The obvious choice seem to be keep the API, port over the implementation to MDC. I don't understand what's up with web components and elm (last I tried, I couldn't get the former to work with virtual dom), and I'm unsure of the ramifications. Insights would be greatly appreciated.

[tolgap]

The link corroborating that statement is at google/material-design-lite repo's README: https://github.com/google/material-design-lite#limited-support

Limited support

Material Design Lite is now in limited support, with development having moved to the Material Components for the web repository.

No further development is taking place in MDL by the core team, but we are happy to review PRs, fix critical bugs and push out new releases. No breaking changes will be accepted.

[debois]

Thanks! (Well, duh. I should learn to read some time.)

[brandonmp]

@debois - I just started playing with Elm, but one thing I've read a few times is that elm-mdl's approach to eliminating boilerplate is at odds with Elm's author's vision language norms & patterns.

This thread on google groups implied that this difference of opinion might be terminal for elm-mdl, as there's some non-zero chance that the future Elm API could introduce breaking changes.

Seeing this roadmap of course implies that you don't agree. So can you opine briefly on how you view your boiler-plate reduction approach wrt core Elm? Do you expect to change the elm-mdl API in the future to comport with whatever patterns Elm decides upon?

I'm just learning Elm, so forgive me if there's obvious background information I'm lacking here--just trying to understand what the UI Kit ecosystem is like in Elm before committing, and elm-mdl is clearly one of the top libraries in that arena.

[nsb]

@brandonmp This should answer your question #253 (comment)

[debois]

@brandonmp: As @nsb commented, we've put some serious effort into getting elm-mdl back into the fold of "mainstream" elm.

[OvermindDL1]

As for web components, most of google's follow Polymer's style (even if they do not use Polymer), that is that properties are set as properties (doable as-is in elm), attributes are set as attributes (doable as-is in elm), 2-way data binding is achieved by having the child component send back an even (catchable and listenable in elm as-is), and the only thing that you cannot do in elm right now is 'be' a web component (by sending events 'up', no way in elm yet that I've seen without a native module or ports). The last bit that has issues is that sometimes elm's VDom likes to walk the children of a web components, which it absolutely should not do. ^.^

For note, I use web components (both vanillajs and Polymer itself) at work (with elm inside a few web components with javascript to do the mappings that elm fails at), they are very nice.

[debois]

I tried Polymer before embarking on elm-mdl, but at the time (elm 0.16), the web-component, say <paper-textfield ...> would polyfill into <div> ..., which the vdom would then "correct" back into <paper-textfield ...>, causing the underlying web component to reset all the time. Can someone help me understand why this is not a problem anymore?

[hakonrossebo]

I don't know the details, but there was a long discussion group thread here

@knewter also has a series of this topic on Dailydrip, with some resources on this page

Richard Feldman summarized some bits here:

• registerElement is enough to get node "my-component" and on "my-component-event" (with a custom decoder) working in Elm
• With the webcomponents-lite.min.js polyfill (16K gzipped), you can get registerElement working on IE11+
• Polymer components in particular...
• Require using Bower
• Reuquire at least webcomponents.min.js polyfill (36K gzipped) for Polymer components which depend on Shadow DOM
• Polymer 1.0 components that use Shady DOM should still work with the smaller webcomponents-lite polyfill
• If children are involved, you need to configure things like this(see below) or else the children will disappear on interaction

(From Rupert Smith)
    <script src="bower_components/webcomponentsjs/webcomponents-lite.js"></script>
    <script>
        window.Polymer = {
            dom: 'shadow',
            lazyRegister: true
        };
    </script> 
https://www.polymer-project.org/1.0/docs/devguide/settings

[pyladune]

Anything decided about direction of elm-mdl V2 ?
I am slowly looking at polymer (elm-polymer) and i wonder if this could simply look like elm-mdl v2 ?

[debois]

@pyladune: Most likely :)

@hakonrossebo: Could you add a link to wherever Richard made the list you put in?

[hakonrossebo]

The list was part of the long discussion - message link here: https://groups.google.com/d/msg/elm-discuss/8Q2xwRh6UYc/oP4CRuLiAQAJ

[darkconsul]

Hi! So i dont understand, what about elm-mdl v2? Any work in progress?

[aforemny]

Closing in favor of #328.

[aforemny]

#328 does not address this yet.