Concerning Function and best practices

Function in practice has unsufficient type-safety, being the super-type of all functions. You better replace it with a function type - see the "Solutions" section down under.

In above example, Function is not assignable to the more narrow onClick function type, which causes the error at hand (Playground example).

In addition to mentioned issue, here is what TypeScript docs say about Function:

This is an untyped function call and is generally best avoided because of the unsafe any return type. If need to accept an arbitrary function but don’t intend to call it, the type () => void is generally safer.

typescript-eslint has discarded Function with the ban-types rule, emitting following message with default configuration (see also here):

The Function type accepts any function-like value. It provides no type safety when calling the function, which can be a common source of bugs. If you are expecting the function to accept certain arguments, you should explicitly define the function shape.

Better solutions

React already comes with built-in event handler-types to handle common events.

type Props = {
  onClick: React.MouseEventHandler<HTMLButtonElement>
};

const Submit = ({ onClick }: Props) => <button onClick={onClick}> click </button>

type Props = { 
  onClick: (event: React.MouseEvent<HTMLElement>) => void
};

void is more restrictive than any. There is no chance to return a value in the callback by accident, which would be possible with any.

In summary, we embrace typing capabilities of TypeScript instead of using Function or any. The parameter now is known to be MouseEvent and the return type void, identifying it as a callback.

Related

Typescript: How to define type for a function callback (as any function type, not universal any) used in a method parameter

Is not enough to type the component in this way:

Yes, that's enough. You don't have to repeat the type of the props, this is just fine:

const Result: React.FC<ResultProps> = ({ prop1, prop2 }) => {
    // ...
};

Playground link

That works because you've already set the type of Result, so TypeScript knows what parameters the function accepts and their types.

A note about React.FC: In the types for React v17.x and below, when you used React.FC for your component, you were saying it supported children. Your component doesn't support children, so I thought I should call it out. Many people started saying not to use React.FC for this very reason: it was easy to accidentally give your component the wrong type information. But in React v18.x and above, they changed the definition of React.FC so that it no longer assumes your component supports children. (If you want to say it does, you add PropsWithChildren like this: React.FC<PropsWithChildren<ResultProps>>.)

So if you're using v17.x or below and you don't want the component to say it supports children when it doesn't, here's an alternative way to do the types for it that you often see:

const Result = ({ prop1, prop2 }: ResultProps) => {
    // ...
};

Playground link

Note, though, that that relies on you returning the correct thing from the component, since there's no return type annotation TypeScript can use to help you if you forget to return something or return something that isn't valid for a component (like returning a plain object). So you might include a return type as well:

const Result = ({ prop1, prop2 }: ResultProps): JSX.Element => {
    // ...
};

Playground link

But again, in the types for React v18.x, React.FC no longer assumes your component supports children.

There are a number of issues with this code, but the particular error that you posted is due to declaring the type of CustomFabric as React.FC<Param> when it is not a function component.

A function component is a function which takes a single argument -- a props object -- and returns some JSX element. Your CustomFabric takes props but it returns a function. So it is inherently incompatible with the React.FC type.

I'm trying to figure out what this code is supposed to do because the typings that you have don't match how you are using it. It looks like text and select are supposed to be components, but your interface says that they are functions which take no arguments and return nothing. If they are components then they should use the React.ComponentType<Props> type.

I also fundamentally don't "get" what the point is of having a controlled input where the state is behind a black box where you can't access it. CustomFabric doesn't seem to give you any access to the state. So I don't see what goal is being accomplished here.

But we can do a better job of properly typing what you have here, which is a function that return a hook. This code fixes most of your issues by declaring that:

• text and select are components which take props value and onChange
• CustomFabric will be called with an object containing components for text and select
• CustomFabric returns a function which takes a name and returns a component. That name must be either 'text' or 'select' and the returned component does not require any props.

There is still a lot of room for improvement. For example your code passes through additional props to the input and select, but these types don't allow for any props other than value and onChange. Your settings only has two properties, so you would get better type inference by dealing with those keys directly rather than looping through Object.entries.

type InputComponent = React.ComponentType<{value: string, onChange: React.ChangeEventHandler}>;

interface PropsTypes {
  text: InputComponent;
  select: InputComponent;
}

export const CustomFabric = (settings: PropsTypes) => {
  const elements = Object.entries(settings) as [keyof PropsTypes, InputComponent][];
  const newSettings = elements.reduce((acc, item) => {
    const key = item[0];
    const Component = item[1];

    acc[key] = (props: any) => {
      const [value, setValue] = useState('');
      const onChange = (event: { target: { value: any } }) => {
        setValue(event.target.value);
      };
      return <Component value={value} onChange={onChange} {...props} />;
    };

    return acc;
  }, {} as Record<keyof PropsTypes, React.FC>);

  return (type: keyof PropsTypes): React.FC => {
    return newSettings[type];
  };
};

Typescript Playground Link

Thanks all for the answers. They are correct but I was looking for a more detailed version. I did some more research and found this on React+TypeScript Cheatsheets on GitHub.

Function Components
These can be written as normal functions that take a props argument and return a JSX element.

type AppProps = { message: string }; /* could also use interface */

const App = ({ message }: AppProps) => <div>{message}</div>;

What about React.FC/React.FunctionComponent? You can also write components with React.FunctionComponent (or the shorthand React.FC):

const App: React.FC<{ message: string }> = ({ message }) => (
  <div>{message}</div>
);

Some differences from the "normal function" version:

It provides typechecking and autocomplete for static properties like displayName, propTypes, and defaultProps - However, there are currently known issues using defaultProps with React.FunctionComponent. See this issue for details - scroll down to our defaultProps section for typing recommendations there.

It provides an implicit definition of children (see below) - however there are some issues with the implicit children type (e.g. DefinitelyTyped#33006), and it might be considered a better style to be explicit about components that consume children, anyway.

const Title: React.FunctionComponent<{ title: string }> = ({
  children,
  title
}) => <div title={title}>{children}</div>;

In the future, it may automatically mark props as readonly, though that's a moot point if the props object is destructured in the parameter list.

React.FunctionComponent is explicit about the return type, while the normal function version is implicit (or else needs additional annotation).

In most cases, it makes very little difference which syntax is used, but the React.FC syntax is slightly more verbose without providing clear advantage, so precedence was given to the "normal function" syntax.