With Frontend libraries like React, we often don't use classes. But the same public/private differentiation can be made through the export keyword. Anything that has an export is public and anything that doesn't is private.
It can be a red flag if a function is exported only for testing. There are a few problems with doing this:
The export could potentially no longer be used in the truly public function of the module (false-positive test)
With the <Card> being the public part. If the <Heading> is only exported to be tested.
export function Heading({ title }) {
return <h1>Title - {title}</h1>
}
export function Card({ title }) {
return (
<section>
<Heading title={title} />
</section>
)
}If the <Card> heading is not testing the Card component directly and the heading is no longer used within it. The tests would still pass giving you a false-positive result.
export function Heading({ title }) {
return <h1>Title - {title}</h1>
}
export function Card({ title }) {
return <section>Whoops no heading</section>
}It makes the implementation of the truly public function less flexible
For example, if the private function is not exported.
function Heading({ title }) {
return <h1>Title - {title}</h1>
}
export function Card({ title }) {
return (
<section>
<Heading title={title} />
</section>
)
}Changing the style of the code to not use a separate <Heading> becomes not a problem.
export function Card({ title }) {
return (
<section>
<h1>Title - {title}</h1>
</section>
)
}A private function is an implementation detail and subject to change.
The private and public differences come from Object Orientated code but I think it's helpful to think about ES modules using functional code in the same way.