Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

teacher tool - don't default export components #9833

Merged
merged 1 commit into from
Jan 26, 2024

Conversation

eanders-ms
Copy link
Collaborator

In the interest of long-term code maintainability, prefer not to use default export unless there is a compelling reason for it. Default exports have a few gotchas that I'd like to avoid:

  • The name assigned to the import can be anything, and doesn't reflect what you're actually importing.
  • They're not discoverable by IntelliSense. You have to open the file to see what you're actually importing. The filename isn't a reliable source of information.
  • During the inevitable refactor/renaming, you must search the code and manually update every import to match the new component name. The compiler can't help you.

Sometimes a default export is the appropriate pattern to employ, but let's not make them the default export pattern we employ. (Did I break your parser? :))

@eanders-ms eanders-ms requested a review from a team January 26, 2024 19:43
Copy link
Contributor

@srietkerk srietkerk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanations of the downfalls of export default, it's super helpful!

@eanders-ms eanders-ms merged commit 732a406 into master Jan 26, 2024
7 checks passed
@eanders-ms eanders-ms deleted the eanders-ms/tt-no-defaults branch January 26, 2024 23:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants