<Dialog /> is not a controlled component

[hronro]

Example:

import React, { Component } from 'react'
import { render } from 'react-dom'

import Dialog, {
  DialogContent,
} from '@material/react-dialog';

class AlwaysOpenedDialog extends Component {
  state = {
    open: true
  }

  render () {
    return (
      <Dialog
        open={this.state.open}
        onClose={() => {
          // I won't do anything in `onClose` so the dialog is expected to be always opened.

          // In a more normally case, I want to close the dialog conditionally
          // if (this.validate()) {
          //   this.setState({open: false})
          // } else {
          //   this.setState(null)
          // }
        }}
      >
        Hello World
      </Dialog>
    )
  }
}

render(<AlwaysOpenedDialog />, document.getElementById('root'))

When I click the mask, the dialog still closed.

According to the React docs, just like the native input element in React, <input type="text" value={this.state.value} onChange={this.handleChange} />, when you try to type something in the input element, this would trigger onChange event, but if you don't change this.state.value in the onChange event handler, the value of this input element won't changed, just like this input element is being locked.

In my opinion, the correct logic for Dialog component is that, when users try to close the dialog(via mouse click or keyboard), this would trigger onClose event, but finally the dialog is closed or not, is depending on the prop open, which respect React controlled components pattern.

[moog16]

Thanks for opening this issue. I realize that this and other components in this library do not follow the controlled component pattern. This repo's main goal is to implement the foundation/adapter pattern of MDC Web.

RE: When onClose is called. Are you saying you do not expect the onClose method to be called on a mouse click/keyboard event?

[hronro]

@moog16 No, I'm saying when users click to close the dialog, this would only trigger the onClose method, but not close the dialog directly. The dialog is finally closed or not is only depend on the prop open is changed or not.

[moog16]

@foisonocean ahhh gotcha - I understand what you're saying now, sorry for the confusion. I do see how this breaks that pattern as you describe, especially when thinking of the onChange method on a input type='text'. I do not have time to get to this until after April (if that). Would you or anyone else like to take a stab?

[dawsonc623]

@foisonocean If you have not started working on this, I can take a look.

[moog16]

I've also noticed this the controlled component pattern is not working in checkbox either...I haven't checked, but this is probably not the case in many of the other components.

@dawsonc623 if you start working on this, this will be a BreakingChange. I think this should be opt-in for the first two months, with a console.warning that says we're going to deprecate. Does that make sense? Similar to what this issue is referencing.

[dawsonc623]

@moog16 That makes sense. Opt-in might be a little tricky - do we just want to make it so if open is present the component is "controlled" otherwise it behaves as it does today? Apart from adding a temporary prop (which I want to avoid if possible) I am not sure how we could retain the way open and onClose work today and still know when the user expects the component to be controlled.

[moog16]

Ya - I think the only way we could do that is with a temporary prop...If we have that, people could slowly migrate over. Its not the best, but its the simplest thing I can think of. I also don't want to break people that have been using this component, and they should be given ample time to upgrade. So let's go with the temporary prop. Could you make sure to comment next to it and open an issue to remove it as well?

[moog16]

@dawsonc623 please be advised @gugu is updating dialog: https://github.com/material-components/material-components-web-react/pull/779/files. You might want to branch from this branch as his code might get in before yours. I'm not sure how quickly you'll finish.

[dawsonc623]

@moog16 I saw that. I plan on branching off of that branch, and if I happen to finish before that gets merged in we can just wait to merge mine until that one is in. That work is already done, so I do not want to risk mucking up that PR with my work.

[moog16]

Cool - Sounds good!

[moog16]

I opened #785 to eventually follow up on the others as well.