Use renderSuggestions as React component rather than calling directly

[lafiosca]

Regarding #44, this patch slightly changes the return type of renderSuggestions and renders it as a React element rather than populating a fragment with its output. This is a subtle distinction but allows the function component passed as renderSuggestions to be hooks-based without having to wrap it in a (props) => ( <MentionSuggestions {...props} /> ) anonymous function.

I will understand if you do not want to incorporate this, as it is potentially a breaking change for people who are returning less typical ReactNode values from their renderSuggestions functions.

[lafiosca]

Thinking about it more, it might make sense to change the parameter name to something that makes it clearer that it's a component if you decide to take this approach.

[GabrielModog]

This change will help a lot. No one to review?

[nanhlua96]

React node include null inside, return null not is feasible in the current code. You don't need change it.

[GabrielModog]

But the way the code was wrote the never will reach the null value and this changes make it possible.

Because the comparison of props if is not a true value will return false, even if the ReactNode return null.

[lafiosca]

@GabrielModog The maintainer implied that this functionality might be in the next major release here: #44 (comment)

@nanhlua96 The type definition for ReactNode includes null, but it also includes a lot of other stuff. It doesn't match the return type of a function component, hence the proposed change:

type ReactNode = ReactChild | ReactFragment | ReactPortal | boolean | null | undefined;

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