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
Export-ing conventions #1275
Comments
In most cases, you should be exporting one conceptual thing from a module. In other words, if you have both "foo" and "boo", those are two modules and thus should be If you insist on having them in the same file (there are some use cases where this makes sense, but not many), then you should be using multiple named exports. When exporting one thing, and inline export is nicer because it ensures that you can not change the binding later (ie, As far as positioning, there will soon be a linter rule in |
The only problem with limiting yourself to one export is it severely limits your ability to use TDD. |
@AMitchemTW that doesn't make any sense to me; how does it limit your ability to use TDD? (not that using TDD is necessarily a good thing) |
If I limit myself to only the default export, I can only test the function from end to end. Ideally, I want to be separating my function into smaller, more testable blocks that are called by my default export. It isn't specifically a problem for TDD, but testing in general. |
Sure; but those smaller blocks a) don't have to be exported at all, and b) absolutely can be imported from other modules. |
However yes, all tests should only be "end to end"; mocking things out makes tests more brittle. TDD doesn't require mocking things out; it just requires testing your interface. |
Tests should absolutely not only be end to end, its the entire reason smaller functions are considered best practise, because its easier to test a small function than a large function. As for you previous comment, I'm not sure I understand. They don't have to be exported but can be imported? |
If you need to test them, you should export them (if they're not exported, they don't need tests). Whether you export them as named exports from the module, or as default exports from their own modules, the only thing that changes is the import path/syntax - their testability is identical. |
Airbnb style guides [10] do not define any specific
export
style, other than:10.6 In modules with a single export, prefer default export over named export.
Which one is the preferred style in the following cases (feel free to suggest better ones):
Single export
Multiple exports
The text was updated successfully, but these errors were encountered: