An example of integrating with React without the Foundation / Adapter pattern

[davidharting]

Notes

This is not a feature request or a bug, so if there is a better way to communicate this, please let me know and I will close this PR.

My main purpose in opening up this issue is to get feedback on this approach for integrating material-components-web with React. Does this simple approach miss anything important?

Integration approach

I am attempting to use material-components-web with React for a production web app. I found a way of integrating with React that is much more lightweight than the Foundation / Adapter pattern.

The basic idea is create and destroy vanilla material-component-web JS components based on the React lifecycle. I hook up the material component to the right element of the DOM by using the react API to get a refence to a DOM element.

Example

import React from 'react'
import { textfield } from 'material-components-web'

export default class TextField extends React.PureComponent {
  
  // Instantiate the vanilla material component once the react component mounts
  componentDidMount() {
    this.mdcComponent = new textfield.MDCTextfield(this.mdcMount)
  }

  // Clean up the vanilla material component along with the react component 
  componentWillUnmount() {
    this.mcdComponent.destroy()
  }

  render() {
    // Note in the second opening div how I get a reference to the DOM element of the text field
    return (
      <div className="mdc-form-field">
        <div className="mdc-textfield" ref={(div) => { this.mdcMount = div }}>
          <input
            type="text"
            className="mdc-textfield__input"
            id="demo-input"
            onChange={this.props.onChange}
          />
          <label htmlFor="demo-input" className="mdc-textfield__label">
            {this.props.label}
          </label>
        </div>
      </div>
    )
  }
}

[flunderpero]

I'm doing exactly the same and I personally think it is just fine if you control all the use-cases of your components. (You might need a componentWillReceiveProps to update a value etc.)

[davidharting]

@flunderpero that's encouraging to hear. Sounds like you have not run into many problems or weirdness with the approach so far?

[flunderpero]

@davidharting everything's working as expected. What I see is that the foundation used in the React example mostly wires up the native components (vie this.refs). It is working fur us right now, but since MDC ist still in very early stages we closely monitor the development (i.e. watch the GitHub repo :-) ) to make sure we don't miss any major change that would affect this approach.

All that said: If I were to write a vanilla awesome-mdc-react package for everyone to use, I'd definitely use the Foundation approach as it seems more future-proof.

[amsheehan]

The beauty part is that you are still actually using the Foundation/Adapter pattern, you just don't have to think about it. If you choose to not interact with the foundation by passing a custom adapter, the component creates one for you with the proper shape, using the element you pass the component. Take a look at the docs for mdc-base for more insight into this.

As an aside, I think this is an absolutely perfect use case for refs. Well done. :)

[amsheehan]

To follow up from before after discussing a little more with the rest of the core team:

There's nothing inherently wrong with this approach on the web. It may get you varying milage component to component. However, some people may want to take an isomorphic approach to their React app, some people may be writing a React Native app, some people may be using a state container.

For these instances, where you need a Material UI library that works across environments, you would need to use the foundation/adapter pattern. This allows us to use components that have different considerations when identifying elements and all that's associated with them in a regular browser environment (capturing/handling events, observing changes, etc...).

We would love to hear any and all ideas for how to make these abstractions easier on frameworks. Please continue the discussion here, update us on the progress of the apps you're building and let us know if there's anything we can do to help!

[davidharting]

@amsheehan Thank you for taking the time to look at this issue and to discuss it with your team!

For my web only use-case, I'm hoping to see how far we can get following an approach similar to the one outlined in my original post. If my team goes this route, I'll be sure to post back here and to explain any successes and roadblocks we come across and how that might inform future work on MDC!

[mikegleasonjr]

I don't think you guys are using the framework differently​ from the intended way, you are just using the default foundation which is the one for the web. So it naturally works.

The exemples in the repo are going the extreme route by creating a whole foundation (see checkbox). They are still using ref and all.

You guys put a doubt in my mind for a second :)

[traviskaufman]

Since there's been no discussion here for a month, closing. That being said, we have begun informal, not-at-all planned out talks about how we can simplify our adapter pattern approach in future releases of the library.

[wzup]

@davidharting

But that doesn't work.
With that approach the label doesn't slide up on focus event. Text is typed over it.

What do I miss? How do you include JS for the component?