Issue 1:
Basically while porting from the old version I get lots of errors while using standard react HTML element properties. For example, whenever I try to add a title property to a button (to get a native tooltip) I get an error. While using tabIndex={-1} on it to avoid focusing via the tab key I get an error. While creating my own component that uses ButtonProps as a base I get that the style property is not defined and so on.

v0.xx types were ok in this regard since they extend their props with extends React.HTMLAttributes<{}> to get this behavior right (although it also meant that it got lots of potentionally invalid properties inserted into the type).

I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

TS should not complain if we try to use standard html properties such as title and so on.

Current Behavior

TS complains that these properties do not exist.

Steps to Reproduce (for bugs)

As an example:

<IconButton title='asdf' tabIndex={-1}/>

Your Environment

Tech
Version

Material-UI
latest beta

React
15

browser
Chrome 60

TS
2.5.2

Issue 2:
We need to discuss how will we standardize the callbacks that some component take in order to behave in a controllable fashion. But since the signature of the callback function they accept is different across components, many new comers get confused.

Therefore, we have to come to a solution on this.

My proposal:

Every controllable component should only be controlled via value and onChange props. No more onRequestXxx.

the value must be as versatile as possible, if it make sense for it to be anything equatable with === then it should be marked as any.

The value should NOT be treated as falsy EVER! Implicit coercion leads to many many bugs.

The signature of the callback must follow this pattern: (e: Event, v: value, ...rest: any[]) => void

If access to the event is granted, there really shouldn't be any reason to provide a reason argument to indicate what triggered the change. The event can be checked against it's type or it's properties. I think this could be more accurate. (debatable 😁 )

@oliviertassinari @newoga @mbrookes Tell me what you guys think 😁

The Roadmap:

1. Standardize The Following Components:

DatePicker: onChange(event, date)

DropDownMenu onChange(event, key, payload) => onChange(event, value, index), index?

IconMenu (event, value)

Drawer (deprecated prop) onChange(event, key, payload) => onChange(event, state)

RadioButtonGroup onChange(event, newSelection)

SelectField, DropDownMenu onChange(event, index, value) => onChange(event, value, index)

Slider onChange(event, value)

Tabs onChange(value) => onChange(event, value) #7741

TextField onChange(event) => onChange(event, value) #3699

TimePicker onChange(null, time) => onChange(event, time)

Table (#3002)

2. Purge State:

Create a stateful StateWrapper components that can be used to make components stateful, useful for forms. It must implement: getValue(), setValue(value), clearValue(), defaultValue prop, onChange prop: (event, value, ...rest) => void

Clear state from all components that can be stateless. As much as possible.

3. Documentation and deployment:

Figure out a way to make usage less pain full, something like:

import SelectField from 'material-ui/lib/SelectField'; // For the actual component
// As opposed to:
import SelectField from 'material-ui/lib/SelectField/stateful'; // For the stateful version component

This is easy to implement, but I don't know if we want this, we should discuss this too.