-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
AirBnb style guide deviation suggestion - use named exports #8641
Comments
If we get rid of our webpack aliases (which we intend to do) all of our imports should be statically analyzable so refactoring tools should allow us to find all usages of a module even if we're using default exports. |
Ah, that would definitely address all except the second bullet point. I still like named exports because it enforces a consistent naming scheme, which makes reading & understanding code easier. Though, readability may not be a strong enough reason to deviate from the style guide. I'd like to throw it out there on Mend-it Monday, even if just for curiosity's sake, to hear some more opinions. :) |
Discussed in mend-it Monday and approved! We should now prefer named exports over default exports. Woot! |
I'm reopening this to get a little clarity about using First, I understand that the following is bad: function foo() {}
function bar() {}
export default { foo, bar }; Here, I agree that named exports make a lot more sense. This module does multiple things, and I may not need all of the methods in that module. By using named exports, we have the ability to do tree shaking and automatic dead code removal, which is awesome. And I don't think there's any question about this case. However, I'm curious about modules that only do and export a single thing. What's correct here, named exports or default exports? It sounds like the consensus was that, contrary to the airbnb styleguide, we prefer to always use named exports. This means that for small modules that do a single thing, instead importing them like this: import createDocumentJobFactory from '../lib/create_document_job';
import licensePreFactory from '../lib/license_pre_routing';
import userPreRoutingFactory from '../lib/user_pre_routing';
import jobResponseHandlerFactory from '../lib/job_response_handler'; I now have to import them like this: import { createDocumentJobFactory } from '../lib/create_document_job';
import { licensePreFactory } from '../lib/license_pre_routing';
import { userPreRoutingFactory } from '../lib/user_pre_routing';
import { jobResponseHandlerFactory } from '../lib/job_response_handler'; It seems like kind of a trivial change, but it now requires that I know how every module names its exports. I see why this might actually sound good, because it's immediately clear when a module exports a named thing that deviates from what we expect, but it feels really heavy-handed. cc: @Bargs since he commented previously here, and @cjcenizal @spalger since they're also involved in the larger Angular styleguide discussion. |
I agree with you Joe, but I also think it's more important we just pick a standard and stick with it. I'm fine with never ever using default exports if that's what's in our style guide. |
I think I've come around on this one. It's nice to enforce consistent A quality editor will also autocomplete the import names, so you shouldn't On Thu, Nov 17, 2016, 1:47 PM CJ Cenizal notifications@github.com wrote:
|
That's why I reopened this. I wanted to make sure we're all on board with only using named exports, mostly because the resolution on this didn't provide any details about the conversation and I think I missed it. If it was already established that we're using only named exports, so be it.
Meaning you're siding with named exports only? That's how I read your reply. |
Maybe it's best to just ask @stacey-gammon to summarize what happened in the discussion about this. If the discussion really was just everyone agree that we should never use |
This is exactly why I've been using named exports whenever I can for the last several months. I haven't regretted once. |
Another nice thing about named imports/exports is the eslint import plugin support. It will verify your named exports/imports so if you mistype the import, or change the name of that import in the source module, eslint can help you find the code you need to update. |
I'm going to close this issue again then, seems people are pretty clearly on board. Thanks! Also, I guess we should both update the styleguide as well as explore enabling that eslint rule then. I don't suppose anyone's bother to look at how much existing code will need to be updated yet. I suspect it's a lot. |
Named exports FTW! Thank you! |
Reopening so that we can get this added to the styleguide |
Add new 'named exports' only rule: #8641
Style guide updated. https://github.com/elastic/kibana/blob/master/style_guides/js_style_guide.md |
As discussed in a prior meeting, we are planning to migrate to the airbnb style guide, but if we have reason to deviate from specific rules, we can discuss as a team. It was mentioned that preference isn't good enough, so I'm going to throw a rule out there I'd like to deviate from and my reasons.
I don't like default exports and, if it were up to me, would require named exports.
Objective reasons:
The text was updated successfully, but these errors were encountered: