The first thing to note is that stateless functional components cannot have methods: You shouldn't count on calling update or draw on a rendered Ball if it is a stateless functional component.

In most cases you should declare the functions outside the component function so you declare them only once and always reuse the same reference. When you declare the function inside, every time the component is rendered the function will be defined again.

There are cases in which you will need to define a function inside the component to, for example, assign it as an event handler that behaves differently based on the properties of the component. But still you could define the function outside Ball and bind it with the properties, making the code much cleaner and making the update or draw functions reusable:

// you can use update somewhere else
const update = (propX, a, b) => { ... };
    
const Ball = props => (
  <Something onClick={update.bind(null, props.x)} />
);

If you're using hooks, you can use useCallback to ensure the function is only redefined when any of its dependencies change (props.x in this case):

const Ball = props => {
  const onClick = useCallback((a, b) => {
    // do something with a, b and props.x
  }, [props.x]);

  return (
    <Something onClick={onClick} />
  );
}

This is the wrong way:

const Ball = props => {
  function update(a, b) {
    // props.x is visible here
  }
    
  return (
    <Something onClick={update} />
  );
}

When using useCallback, defining the update function in the useCallback hook itself or outside the component becomes a design decision more than anything: You should take into account if you're going to reuse update and/or if you need to access the scope of the component's closure to, for example, read/write to the state. Personally I choose to define it inside the component by default and make it reusable only if the need arises, to prevent over-engineering from the start. On top of that, reusing application logic is better done with more specific hooks, leaving components for presentational purposes. Defining the function outside the component while using hooks really depends on the grade of decoupling from React you want for your application logic.

Another common discussion about useCallback is whether to always use it for every function or not. That is, treat is as opt-in or always recommendable. I would argue to always use useCallback: I've seen many bugs caused by not wrapping a function in useCallback and not a single scenario where doing so affects the performance or logic in any way. In most cases, you want to keep a reference while the dependencies don't change, so you can use the function itself as a dependency for other effects, memos or callback. In many cases the callback will be passed as a prop to other elements, and if you memoized it with useCallback you won't change the props (thus re-render) other components independently of how cheap or costly that would be. I've seen many thousands of functions declared in components and not a single case in which using useCallback would have any down side. On the other hand most functions not memoized with useCallback would eventually be changed to do so, causing serious bugs or performance issues if the developer doesn't recognize the implications of not doing so. Technically there is a performance hit by using useCallback, as you would be creating and additional function but it is negligible compared to the re-declaration of the function that always has to happen either you use useCallback or not and the overall footprint of React and JavaScript. So, if you are really concerned about the performance impact of useCallback versus not using it, you should be questioning yourself if React is the right tool for the job.

All React Function Components are regular Javascript functions.

Not all regular Javascript functions are React Function Components.

Function components are just a signature for a specific function.

You can look at the Typescript definition to see exactly what that signature is:

    interface FunctionComponent<P = {}> {
        (props: PropsWithChildren<P>, context?: any): ReactElement<any, any> | null;
        propTypes?: WeakValidationMap<P> | undefined;
        contextTypes?: ValidationMap<any> | undefined;
        defaultProps?: Partial<P> | undefined;
        displayName?: string | undefined;
    }

Reference: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/v17/index.d.ts#L542

And PropsWithChildren is defined as:

type PropsWithChildren<P> = P & { children?: ReactNode | undefined };

Reference: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/v17/index.d.ts#L822

The JSX parser will translate JSX and pass certain parameters to these functions.

JSX:

<CompOne someProperty="someValue"><CompTwo/></CompOne>

Equivalent to:

CompOne({someProperty: "someValue", children: CompTwo({})})

The signature is just letting you know how the JSX will be parsed, so you know how to access those parameters within your function.

The signature includes some additional info as well: the function should return a ReactElement or null, and it can have those four properties.

For example, I'm trying to log the someProperty value from CompOne:

<CompOne someProperty="someValue" someOtherProp="someOtherValue" />

CompOne(someProperty) {
  console.log(someProperty); // logs {someProperty: "someValue", someOtherProp: "someOtherValue"}
  return null;
}

This is incorrect, because I was not using the function as the Function Component signature describes. The JSX parser reads the properties into an object, and passes it as the first parameter to the function. Although the code will still execute, it is not what I intended to happen.

CompOne(props) {
  console.log(props.someProperty); // logs "someValue"
  return null;
}

This works as intended because I know the structure of a Function Component.