Motivation

Currently makeStyles always returns a function which optionally requires props.
I think this is a typings bug because props should be required if the props are needed to create the styles.
With my change if you specify a non empty type for the props the argument of the returned function would be required, otherwise optional.

export interface MyComponentStyleProps {}
export interface MyComponentProps extends MyComponentStyleProps {
  [...]
}

const MyComponent: FC<MyComponentProps> = ({[...]}) => {
  const styles = useStyles();

  return (
    <AnotherComponent />
  );
};

const useStyles = makeStyles((theme, props: MyComponentStyleProps) => ({
  [...]
}));

Since MyComponentStyleProps is an empty object props would not be required.

const MyComponent: FC<MyComponentProps> = ({[...]}) => {
  const styles = useStyles();

  return (
    <AnotherComponent />
  );
};

const useStyles = makeStyles((theme, props) => ({
  [...]
}));

If you don't specify a type props wouldn't be required either.

export interface MyComponentStyleProps {
  customStyle: any;
}
export interface MyComponentProps extends MyComponentStyleProps {
  [...]
}

const MyComponent: FC<MyComponentProps> = ({
  customStyle,
  [...]
}) => {
  const styles = useStyles({customStyle});

  return (
    <AnotherComponent />
  );
};

const useStyles = makeStyles((theme, props: MyComponentStyleProps) => ({
  [...]
}));

Now you will have to specify props otherwise useStyles will error out.

I would have rather preferred to let the user specify the generic (ex. makeStyles<MyComponentStyleProps>((theme, props)) but that would force you to specify all generics so you won't be able to infer the stylesheet type for the second generic.
Once microsoft/TypeScript#54047 gets merged it should be possible to do so.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• Jest Unit Test
• Checked with example app
• Checked with production app

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation using yarn docs-build-api
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

Additional context