I see that the following is fine:
const Tab = connect( mapState, mapDispatch )( Tabs );
export default Tab;
However, this is incorrect:
export default const Tab = connect( mapState, mapDispatch )( Tabs );
Yet this is fine:
export default Tab = connect( mapState, mapDispatch )( Tabs );
Can this be explained please why const
is invalid with export default
? Is it an unnecessary addition & anything declared as export default
is presumed a const
or such?
6 s
const
is like let
, it is a LexicalDeclaration (VariableStatement, Declaration) used to define an identifier in your block.
You are trying to mix this with the default
keyword, which expects a HoistableDeclaration, ClassDeclaration or AssignmentExpression to follow it.
Therefore it is a SyntaxError.
If you want to const
something you need to provide the identifier and not use default
.
export
by itself accepts a VariableStatement or Declaration to its right.
The following is fine
export default Tab;
Tab
becomes an AssignmentExpression as it’s given the name default ?
export default Tab = connect( mapState, mapDispatch )( Tabs );
is fine
Here Tab = connect( mapState, mapDispatch )( Tabs );
is an AssignmentExpression.
Update: A different way to imagine the problem
If you’re trying to conceptually understand this and the spec-reasoning above is not helping, think of it as “if default
was a legal identifier and not a reserved token, what would be a different way to write export default Foo;
and export default const Foo = 1;
?”
In this situation, the expanded way to write it would be
// pseudocode, this thought experiment is not valid JS
export default Foo;
// would be like
export const default = Foo;
export default const Foo = 1;
// would be like
export const default const Foo = 1;
// so would the following line make sense?
const bar const Foo = 1;
There is a valid argument the expansion should be something like
// pseudocode, this thought experiment is not valid JS
export default const Foo = 1;
// would be like
const Foo = 1;
export const default = Foo;
However, this then would become ambiguous per Sergey’s comment, so it makes more sense to write this pattern explicitly instead.