Rmwc: Foundation Adapter Implementation

[lynnmercier]

Is there a reason why you chose to wrap the MDC Web vanilla implementations of components, instead of using the foundation/adapter pattern?

[jamesmfriedman]

Hi @lynnjepsen!

A few reasons.

• While it would be nice to have a direct foundation implementation, it's a very large scope of work to keep up with. Compare implementations of MWC React Checkbox Example vs RMWC Checkbox.
• Wrapping the components and only exposing necessary api details seemed like the safest way to protect against future breaking changes. When internal improvements happen to the components, RMWC can get the updates without having to change.
• When I started this project, I lacked in-depth working examples. There was a checkbox React example in the framework-examples directory and I compared it to the Preact implementation listed in your Readme. After weighing the pros and cons, I felt the strategy Preact took offered the path of least resistance.

I'm not saying any of these reasons are right, it's just the path I ended up taking. For some components it's been easy to manage, for some of the more complex ones it can be a bit trickier. I ultimately want to have one component library that can render on both React Web or Native and I believe that would necessitate a full foundation implementation. I don't exactly know where to begin tackling that one though.

Your thoughts and opinions are greatly appreciated.

[SleeplessByte]

From what I understand, the foundations are móre stable than the rest of the API, and are meant as a full fledged advanced way to integrate with any other framework and/or library.

https://github.com/material-components/material-components-web/blob/master/docs/integrating-into-frameworks.md#the-advanced-approach-using-foundations-and-adapters
https://github.com/material-components/material-components-web/blob/master/docs/code/architecture.md

This vue adapter is very cool and since it's very similar to React, this would probably be a very worthwile effort. I wonder how that would tie into one lib for web + native, but you can probably pipe / switch / branch on the differences since the rest of the implementation would be the same.

https://github.com/stasson/vue-mdc-adapter
https://stasson.github.io/vue-mdc-adapter/

[jamesmfriedman]

Yeah since she posted this issue, I’ve realized a lot of the subtle issues that have popped up would be avoided with a direct implementation. I’m going to start with the low hanging fruit and slowly move over the library through releases.

[jamesmfriedman]

@lynnjepsen I started digging into doing a direct foundation implementation, and I like it. Overall it should result in better performance and fix these small edge cases we've been running into.

Great pattern. I'm hoping it could eventually result in one library that I can render on both mobile and web with just swapping out the foundation adapter.

[jamesmfriedman]

The first components using the Foundation implementation are being rolled out in the next release. https://github.com/jamesmfriedman/rmwc/pull/165

[jamesmfriedman]

https://github.com/jamesmfriedman/rmwc/pull/170 Fixes server side rendering and adds tests for foundation components..

[jamesmfriedman]

TextField, Select, Dialog, and ChipSet have all been added in 1.5 #183

[SleeplessByte]

@jamesmfriedman I've been using these. So far they work greatly!

[jamesmfriedman]

Thanks @SleeplessByte, glad they're working as intended. The future is looking bright since this will stay almost completely in sync with the core MDC package.

[j-o-d-o]

The only thing I worry about a little bit is finding all the changes in the new versions. Previously there was basically a summary in the changelog within the _feature_ and _breaking changes_ section. Now there is the possibility that some internal code is changing that does not affect the public API (and therefore is not documented) but could affect RMWC.

[jamesmfriedman]

That’s why I’m committed to improving the test suite and coverage. There has already been a lot of improvement in this area with adding tests for server side rendering and multi react version testing. I want to add cross browser and snapshot testing as well. Mix that in with a goal of 100% test coverage and we should be pretty well prepared to find broken functionality.

Also, since everything is getting piped through a syncsWithPropa function and using the public part of the vanilla js api, and breaking foundation or adapter change should be immediately discoverable.

[jamesmfriedman]

Thanks for the challenge @lynnjepsen. This task will be completely out in the wild with the release of #241.

[groovenectar]

Great stuff :)

People have mentioned that using Foundation, it becomes possible to translate a codebase into native mobile.

Is that a documented process via either RMWC or MWC? I've not been able to dig up much information on the implications of the update or the approach to the native component counterparts...