Skip to content
This repository has been archived by the owner on Jan 28, 2021. It is now read-only.

default-exports #52

Open
joshmccall221 opened this issue Nov 28, 2017 · 4 comments
Open

default-exports #52

joshmccall221 opened this issue Nov 28, 2017 · 4 comments

Comments

@joshmccall221
Copy link
Contributor

https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad

@travi
Copy link
Contributor

travi commented Jan 31, 2018

i think we still encourage default exports for react components, but should at least not restrict for normal modules (maybe even encourage not to use default exports in those cases?)

thoughts @richardson-trevor?

@trevtrich
Copy link
Member

Have you come across any sort of "show me the data" downsides that are against default exports? He mentions tree shaking, but we don't really use the pattern he talks about (exporting a big object as default that has all the funcs in it).

I like the fact that the default export is thought of as "THE" module, but I wish you could lock in the name on it. Then I would be totally for default exports whenever possible. That gives the benefit of referring to the same function or react component with the same name all the time.

In short, I'm torn/indifferent with the current standard. I really don't like the idea of the import {MyComponent} from 'my-component', but yet that does allow us to always refer to things in the same way.

@travi
Copy link
Contributor

travi commented Feb 1, 2018

the thing that sells me is the effort involved if/when the module starts exporting a second function. its less important to me that the import is named the same everywhere, but when i have to find all the imports and change it from a default import to a named import, that refactor became a lot more expensive.

when we lint for a single export being default, i think it can drive default exports that arent necessarily "THE" export, just "only". both because its the "only" for this commit, even tho others are planned with upcoming iterations, ad because of cases where "THE" isnt important. there certainly can be cases where "THE" export can be/is meaningful, but a lot of times its not as meaningful. does that make sense?

i think default exports for components are almost always meaningful. maybe we limit linting to that, but leave the decision up to the author for normal modules?

@trevtrich
Copy link
Member

That sounds fair to me. I still hold out hope that there could someday be a named export of sorts that is a single name. Literally the only part that bothers me is that the semantics of doing import {BLAH} suggests there are other options. Otherwise I'd love to go that direction. Given the current state of the world, I agree with you, I think the better option for components is to use default export and to let the author decide for regular modules.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants