Dialogue component doesn't size to width specified by user

[niole]

Problem Description

When I specify a width for the Dialogue component, it doesn't size to the width I want, but 75% percent of that. Also, if I specify a width, the component does not center itself accordingly. I am specifying the width via the style attribute e.g.:

<Dialogue
   style={{ width: 500 }}
/>

I realize that this style attribute corresponds more to the width of window.

As the background behind the modal always grays out the entire screen and not only the user specified width, it doesn't make sense for the style props's width key to correspond to the width of the window.

I find this unintuitive and think the usability of this component could be revised so that it corresponds more to how a user would approach it's customization.

I would include a screen shot, but I'm working under NDA.

Versions

• Material-UI: 0.14.4
• React: 0.14.7
• Browser: Chrome

[alitaheri]

@niole you should use contentStyle for that and also set maxWidth to none, take a look at the Styled Dialog example here

[niole]

Thanks for the reply. Is there a reason for the dialog having such specific functionality? Do you think it would make more sense to have width refer to dialog's inner panel and have the more specifically named width prop for the outer part?

[alitaheri]

@niole It was like that once, I added that prop and then we saw the complexity it would introduce so we deprecated it and added an example to demonstrate how it should be done. the complexity comes from maxWidth. There are no good ways to have props controlling all that without over complicating the component.

[niole]

Speaking of overcomplication, I have also been experimenting with the
buttons. They look great, but seem to hinder performance in highly
interactive UIs. Is it just me or can you think of any reason why that
would happen?
On Mar 13, 2016 11:52 PM, "Ali Taheri Moghaddar" notifications@github.com
wrote:

@niole https://github.com/niole It was like that once, I added that
prop and then we saw the complexity it would introduce so we deprecated it
and added an example to demonstrate how it should be done. the complexity
comes from maxWidth. There are no good ways to have props controlling all
that without over complicating the component.

—
Reply to this email directly or view it on GitHub
#3675 (comment)
.

[alitaheri]

@niole No all our components are slow right now. Because they have heavy render functions and they don't implement shouldComponentUpdate. We plan on changing all that so they become faster. But for now you can wrap our components and implement shouldComponentUpdate yourself. We can't do it yet because we have other plan that would make the implementation unnecessary.

[niole]

No kidding. My first instinct would be to use shouldComponentUpdate to save performance. What else would you do to save performance in a react component?

[alitaheri]

@niole shouldComponentUpdate is useless ( if not harmful ) with props that always change with each render. The perfromance problem is our render functions too many calls to Object.assign which performs one of the slowest operations in javascript ( object key iteration ). So we should fix that if we hope to improve performance, not just another function that does the same thing only to always return true.

[niole]

This has been really informative! Closing ...