React functional component vs. plain-old JS function that returns React element

Question

Suppose I define a simple React functional component like this:

const Greeter1 = ({name}) => <h1>Hello {name}</h1>;

I can also define an equivalent plain-old JS function that returns a React element, like this:

const Greeter2 = name => <h1>Hello {name}</h1>;

The "React" version is of course also just a normal JS function, taking in a JS object instead of a string. We could use either of these functions within plain JS to get the greeter element for a given name, just with slightly different caller syntax:

const greeterElement1 = Greeter1({ name: "Bob" });
const greeterElement2 = Greeter2("Bob");

Within a React expression though, we can call these functions in a few different ways:

const someReact1 = <div>{ Greeter2("Bob") }</div>;
const someReact2 = <div>{ Greeter1({ name: "Bob" }) }</div>;
const someReact3 = <div><Greeter1 name="Bob" /></div>;

My question: Are there any effective differences between these calling styles other than syntax aesthetics? I assume someReact1 and someReact2 are virtually identical, but I'm not sure about someReact3. Does using the React component syntax change the way React treats things? Does it affect behavior or performance in any way? Or is it merely syntactic sugar?

When doing a diff on the virtual DOM tree, does React forgo comparing within a functional component if its attributes haven't changed between renderings? And if so, am I correct to assume that that optimization would be lost when calling functions directly as in someReact1?

I want to know b/c in some cases I actually prefer the style of someReact1 as it allows me to use functional programming techniques like currying more easily, plus sometimes it's nice to not have to specify parameter names when calling. But am I paying some kind of penalty by doing so? Am I better off sticking with the traditional syntax?

Answer 1

Component functions are (a bit?) faster than class components since React 16. Not sure if it's true for prior versions.

Calling component function as a function is much faster than calling it via JSX/React.createElement. But, in most cases, this should not affect the way we write our code since JSX is pretty readable. To fill this gap we should use @babel/plugin-transform-react-inline-elements.

However, I understand your passion to call them as functions. For the sake of composition, I also find it quite useful. This is even more true for plain functions.
But, again, in the future, functional components are going to have a state. If it happens, we may regret our passion :)

Plain functions seem to be faster than component functions. However, I have not digged this topic yet. For example, I'm unsure if it works OK with react-hot-reload. Or, its pros/cons for performance and possible optimizations.

---

IMO, no matter the differences and in any case, optimizations are still on us - be it a shouldComponentUpdate, or memoization, or keys. Components which might not need any optimizations should be cheap to re-render, and vice versa (if it is a pure calculation, not DOM operation, obviously).

Feel free to comment or correct, I'll update my post.