Material-components-web: Decide the future of our framework examples

[lynnmercier]

Our framework examples currently serve as example code for how to wrap MDC Web in various frameworks

• Angular 2
• Aurelia
• Preact
• React
• Vue

This has some benefits

• We keep Real Code to test our Foundation/Adapter architecture against
• Lets us document some examples of how Foundation/Adapter works with frameworks

But it also has one key problem: We often have to triage issues in the community that are specific to one of these frameworks. We do not have "experts" for each of these frameworks who can help resolve these issues, so we often have unsatisfying replies to these issues.

@amsheehan suggested that we start a list on our README with links to _other_ repositories which wrap MDC Web in a framework. For example. @prateekbh could submit a PR to the MDC Web README, which adds a link to his preact material components. Then MDC Web could direct all preact specific issues to that repository.

And, of course, @prateekbh can still send MDC Web PRs whenever our Foundation/Adapter code needs tweaking to better support preact.

I really like this suggestion, but wanted to open it up as a discussion, in case there was other feedback.

[prateekbh]

Sounds good!
Just one thing: maybe before we add the links to README, we can look into the project with the most minimum requirement that the package does not break the _al-la-catré_ delivery model. I have seen projects which just bundle everything in one js file and hurt more than gains.
Thoughts?

[trimox]

Great idea. I'd suggest grouping by type of MCW implementation method (e.g. using Foundation API or wrappers of the vanilla components).

Glad to see the discussion and the opportunity to demonstrate MCW using Angular..
Sign me up,
Angular MDC

[amsheehan]

@trimox There's an example in our demos that will prevent the FOUC when toggling the start aligned snackbar 😄

Angular MDC looks great!

[Garbee]

I would urge when doing a "list of implementations" to have some quality control mechanisms in place. Something to the effect of:

• Project submissions must have existed for longer than 6 weeks.
• Should show continued maintenance over time
• Provide usage documentation to users

etc. Just some small rule-set that would help make it clearer whether something should be included and continue to be included. Also limit the number of projects per implementation. There can't really be 8 highly recommended ReactJS wrappers. Try to focus on the real top ones based on the rule criteria set in place. Like 4 recommendations is a good maximum. Someone could easily sit down in a day and experiment with that many versions to see which one has an API they prefer.

[trimox]

@amsheehan, thanks! Updated the Snackbar demo 😄
@Garbee, I like the quality control ideas, and it'll be reassuring that an MCW implementation had been vetted.
Just wanted to say, the MCW team's has created the magnum opus of Material Design on the web. Keep up the great work!

[lynnmercier]

Yay all great ideas. I'll try and start pulling this into our docs soon.

[nickmccurdy]

Thanks for all the work that's gone into designing, documenting, and implementing of these framework agnostic components. I think it would be great to document a list of framework specific wrapper projects, while also clarifying in the documentation that this project is not meant to wrap components for framework specific purposes directly.

I first found this project via react-mdl, which is now deprecated and links to this repository. As a result, I expected this project to expose React wrapper components directly. Based on the readme's and home page's wording, I thought that the mentions of framework adapters meant that there was already a system in place for automatically wrapping these components for specific frameworks. In retrospect it seems like there isn't a universal automatic wrapper because of the extensible architecture, but #840 seems like a great way to simplify this.

For now, I think it would be a good idea to recommend specific framework wrappers in the readme, making the purpose of this project more clear for users that want framework bindings, while explaining that foundation/wrapper implementation is meant for more complex use cases (like in the implementations of these framework wrappers).

Here are some of the framework specific wrappers I've found so far, with more dependent wrappers on npm:

• https://github.com/kradio3/react-mdc-web
• https://github.com/kripod/material-components-react
• https://github.com/petejohanson/vue-mdc
• https://github.com/haoxins/react-mdc
• https://github.com/react-mdc/react-material-components-web

[Garbee]

Honestly, right now I would not recommend a single React wrapper. They are very early and their documentation is extremely lacking and outright incorrect in different cases. At least of the 2 or 3 I've tried to use.

Linking to other projects should not be jumped to. First, set standards for recommendations. Then analyze what is available and see if anyone meets those standards. Once someone does, then link to them.

If we link to projects that are difficult to use, that only hurts adoption and the project's reputation.

[nickmccurdy]

I agree that many of the wrappers (most of the React wrappers from what I've seen) are not production ready yet (they definitely need more documentation) and standards are important. I still think it would help to link to projects that users can contribute to (maybe limiting them to ones that use foundation and separate importable files), though maybe this should be in the contribution docs instead of the readme. I would still like to have information in the documentation explaining that this project doesn't provide framework specific wrappers directly, and it could link to the contribution docs for more information.

[codedbypaul]

I've been reading through the framework examples and was wondering how easy it would be to combine 2 or more foundations/adaptors into a new component.

For example a search component that imported the button and textfield foundation/adaptor.

Would this even be possible?

[Garbee]

Search would be its own component that you then use textfield/button/whatever inside of. It doesn't need to be its own isolated thing that you pull and mesh everything together into one pot.

Components are each a specific piece to do a task. You then use those pieces to compose the higher level interactions (such as search.)

[SergiiVlasiuk]

The link provided for frameworks integration does not work now. Could I have a chance please to have the examples (in general I'm interesting in material-components-web and Angrular integration)?

[robbyrice]

It seems that the framework integration examples were moved to the main README.md