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.

The issue isn't when passing the function, it's when destructuring the props and providing a default function:

{ createCard = f => f }: dataFormProps

This code indicates that createCard should be a function which accepts a parameter and returns a value. Which it doesn't:

createCard: ()=>void

Make the default parameter match the signature:

{ createCard = () => {} }: dataFormProps