Standardizing our "export default" design pattern

[philipmjohnson]

When implementing React components that require a wrapping with withTracker(), our code often looks like this:

const Foo: ReactFC = () => {
  :
}

const FooContainer = withTracker(() => ...)(Foo);

export default FooContainer;

The problems with this approach are:

• We create a variable called FooContainer which has little utility. I am not sure it even provides explanatory power.
• It can lead novice developers to write import FooContainer from 'Foo.tsx' rather than our standard practice of import Foo from 'Foo.tsx'

In other cases, we don't define the ephemeral FooContainer variable at all:

const Foo: ReactFC = () => {
  :
}

export default withTracker(() => ...)(Foo);

This solves both of the above problems.

I think we should standardize on one of these approaches.

Question: are there any compelling reasons to prefer the first pattern over the second?

Proposal: if we prefer the second pattern, then let's create a good first issue to go through the code base and update it to get rid of the "*Container" declarations. (Or go through the code and add *Container declarations, if we decide that alternative is actually better.)

[cammoore]

We should use the direct export default version.

I can see a situation where we might need another const before the export default, using a higher-order component to wrap Foo before the export default withTracker. This was needed when we used redux, but since redux is gone it shouldn't happen very often.

Do we have a naming convention for the interface that defines the props for Foo? I propose

interface FooProps {
  :
}

const Foo: React.FC<FooProps> = ({ ... }) => {
  :
}

[trey-sumida]

I prefer the second method of directly exporting the withTracker. As long as there is no underlying need for the withTracker to be assigned to a const, it is far easier to understand what is happening when the withTracker is directly exported.