Question regarding latest (beta.43) WithStyles update.

[emreeren]

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

Expected Behavior

Sample code to compile.

Current Behavior

does not compile with that error

Type '{ caption: string; }' has no properties in common with type 'IntrinsicAttributes & StyledComponentProps<"content"> & { children?: ReactNode; }'.

Steps to Reproduce (for bugs)

1. Try to compile the sample code

import { withStyles, WithStyles } from 'material-ui';
import * as React from 'react';
import './App.css';

interface IStyle {
  content: any;
}

interface IComponentProps {
  caption: string;
}

type ComponentProps = IComponentProps & WithStyles<'content'>;

const decorate = withStyles((theme): IStyle => ({
  content: {
    margin: 4
  }
}));

const Component = (props: ComponentProps) => {
  return <div className={props.classes.content}>Hello {props.caption}</div>
}

const StyledComponent = decorate(Component);

class App extends React.Component {
  public render() {
    return (
      <div className="App">
        <StyledComponent caption="Developer" />
      </div>
    );
  }
}

export default App;

Context

The sample code was compiling fine before beta.43 update. Now I need to change

const StyledComponent = decorate(Component);

line as

const StyledComponent = decorate<IComponentProps>(Component);

to make it compile without errors.

I'm not sure if it is a bug or an intentional change so I wanted to ask before attempting to change my all styled components. I think this probably relates with #11003

Your Environment

Tech	Version
Material-UI	v1.0.0-beta.43
React	16.3.2
browser	Chrome
typescript	2.8.3

[estaub]

@emreeren No, it was very much not intentional!

@pelotom Reversing the order of the alternative function types returned by withStyles seems to fix this particular case. Do you recall if you had a reason (test case) for the original order?

export default function withStyles<ClassKey extends string>(
  style: StyleRules<ClassKey> | StyleRulesCallback<ClassKey>,
  options?: WithStylesOptions,
): {
    <P extends ConsistentWith<WithStyles<ClassKey>>>(
        component: React.ComponentType<P & WithStyles<ClassKey>>,
    ): React.ComponentType<P & StyledComponentProps<ClassKey>>;
  (component: React.ComponentType<WithStyles<ClassKey>>): React.ComponentType<
    StyledComponentProps<ClassKey>
  >;
};

[pelotom]

Nope, reversing the order seems like the right move as long as it satisfies the rest of our test cases. We should add this example as a test case too.

[estaub]

@emreeren The bug does not occur if

`"strictFunctionTypes": true`

is set in tsconfig.json.

@pelotom Swapping the order of the function-overload alternatives now fails where one might suspect: the no-props case. I've no idea of how to fix the reversed case.

It seems over-presumptive to me, but I need to ask: is it reasonable to require strictFunctionTypes be set? Reading the doc, it's very clear how it makes the released implementation work. It's been out since 2.6, so I'd expect that most published declarations are good with it.

[pelotom]

I think it's reasonable to expect that people use strictFunctionTypes if they want an optimal experience.

[emreeren]

Sounds good. Unrelated but at my first attempt I've got an issue because of this. ReactiveX/rxjs#3031

[estaub]

@ljvanschie Does changing to
"strictFunctionTypes": true
work for you?

[ljvanschie]

@estaub I've tried the setting, but it caused some other problems with stateless functional components that use withStyles. We ended up just adding the generic props parameters to the decorates.

[pelotom]

@ljvanschie if it caused problems, you should probably pay attention to them... it’s helping you find bugs!

[geirsagberg]

I ran into the same problem as OP, enabling strictFunctionTypes made the error go away. This should probably be documented though.

[geirsagberg]

Actually, enabling strictFunctionTypes caused a whole bunch of problems for other places in our code. Possibly a symptom we should look into, but is it really necessary for Material UI to require everyone to use strictFunctionTypes?

[pelotom]

I looked into this some more and I don't think this has anything to do with strictFunctionTypes... you can fix it by just making your classes prop optional:

type ComponentProps = IComponentProps & Partial<WithStyles<'content'>>;

Since ComponentProps represents the "outward-facing" view of your component, i.e. what a user of the component deals with, classes is optional for them.

[pelotom]

Actually, it should really be

type ComponentProps = IComponentProps & StyledComponentProps<'content'>;

but the typings are subtly wrong to make that not work... I will fix that.

[geirsagberg]

The point is that the inner classes prop should be hidden for the consumer, shouldn't it? For example, many MUI components have a separate outward facing classes prop used to override the inner CSS styles, and only the specified keys should be allowed, e.g. root for Card

[pelotom]

@geirsagberg I'm not sure what you mean... classes is visible both within the component and to a user of the decorated component; in the former case it's guaranteed to be there and have all class names set, in the latter it's optional, and all properties within it are optional (because it represents overrides).