Material-ui: ButtonProps className make SpeedDial unclickable

[janhesters]

• [x] This is not a v0.x issue.
• [x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior 🤔

The button should get the class and still work.

Current Behavior 😯

It is unclickable (and in general all on<event> methods won't work).

Steps to Reproduce 🕹

Link: https://codesandbox.io/s/xon8qz939p

1. Give speed dial ButtonProps: {{ className: 'something' }}

Context 🔦

I was giving it a class to apply custom styles.

Your Environment 🌎

| Tech | Version |
|--------------|---------|
| Material-UI | v4.0.0-beta.1 |
| React | 16.8.6 |
| Browser | Chrome |
| TypeScript | None |
| etc. | |

[oliviertassinari]

@janhesters So far, we plan on removing the SpeedDial component from the lab to focus on more useful components. What's your use case of it?

[janhesters]

@oliviertassinari Oh no 😱 We use it in production (and love it). Please keep it ❤️

Our use case is that it allows a very consice UI when used with tables. Here is a GIF:

In general it combines well with any UI on mobile and on desktop. It's occasionally not easy to get users to understand it, but with proper onboarding (e.g. with Joyride) it works well.

[oliviertassinari]

@janhesters Well, using our analytics stats, it's the least used component. We will see.
Looking at the source, ButtonProps overrides the className. We have solved the same problem for the PaperProps prop in the Dialog component in the past. Are you interested in reproducing the same fix? :)

[janhesters]

@oliviertassinari That is sad to hear. I think it would get more usage once it's merged in core, but I'm biased 😄

Are you interested in reproducing the same fix? :)

Yep! I'm gonna do a quick PR.

[janhesters]

Here is the PR: https://github.com/mui-org/material-ui/pull/15652

[mbrookes]

So far, we plan on removing the SpeedDial component from the lab

Is that a "Royal we"? 👑 🙂

You suggested it, but it was never discussed in detail, never mind agreed.

My proposal was to keep it in the lab as a community supported component. (i.e. PR's aren't guaranteed to be reviewed by the core team, but will be merged if they are reviewed by someone other than the contributor.)

@janhesters

We use it in production (and love it).

Could you make the issue title something less hyperbolic then? 🙂

[janhesters]

@mbrookes

My proposal was to keep it in the lab as a community supported component.

Love it.

Could you make the issue title something less hyperbolic then?

Done 👌

[oliviertassinari]

@mbrookes I was using the following assumption: we build the most requested components (10 new?). We have tons of issues to handle with them. We look back at the analytics states, we see that the speed dial is still the least used component, everybody agrees to drop it. Now, there is a lot of if, the future will tell is in 6 months. The discussion started in https://github.com/mui-org/material-ui/issues/12830#issuecomment-456542241, our prioritizes have evolved since then toward supporting more components.

[hburrows]

This issue isn't about keeping or removing support for the SpeedDial component but the topic is being discussed here so I'll chime in and also express strong interest in continuing to support the SpeedDial component, at least in the lab if not in moved into core. I respect what the analytics might say but it's a high-value component and those that are using it (and I'm one of them) are likely using it in a very prominent/important way and place. I regularly see issues related to the SpeedDial component which tells me it's far from unused. I'm urging you to continue supporting the component. I get that you need contributors to help and I'll do what I can help move this component along.

[mbrookes]

@hburrows Thanks. I'll mark the "future of SpeedDial" comments as off-topic to keep this issue on-point. We can open a new issue for this if it warrants further discussion on the future.