为什么我不再使用 export default 来导出模块 #5046

Hopsken · 2019-01-24T11:54:22Z

译文翻译完成，resolve #5030

up to date

update

sync

update

Fengziyin1234 · 2019-01-24T14:23:06Z

@fanyijihua @Hopsken 校对认领

fanyijihua · 2019-01-24T14:23:12Z

@Fengziyin1234 好的呢 🍺

SHERlocked93 · 2019-01-25T02:05:23Z

@leviding 校对认领

fanyijihua · 2019-01-25T02:05:25Z

@SHERlocked93 妥妥哒 🍻

Fengziyin1234

@fanyijihua 校对完成 @Hopsken 翻译的好棒！只有一个英文没有删掉的地方需要改，别的都是提供一些选项。

Fengziyin1234 · 2019-01-25T03:53:20Z

TODO1/stop-using-default-exports-javascript-module.md


-6.  **Cognitive overhead slows down development.** Put simply: the more detail you need to remember to be productive when writing code, the slower your development will be.
+6.  **心智负担会拖慢开发速度**。简单来说，编码时，你需要记忆的用来保证效率的细节越多，你的开发速度越慢。


你觉得心智负担和认知负荷哪个更好？我不太知道该怎么翻译，我会翻译成认知负荷。我就是提供点选项。

Fengziyin1234 · 2019-01-25T04:01:08Z

TODO1/stop-using-default-exports-javascript-module.md


-## Worse tooling support
+## 糟糕的工具支持Worse tooling support


不小心带进去了英文

Fengziyin1234 · 2019-01-25T04:06:44Z

TODO1/stop-using-default-exports-javascript-module.md


-I’ve had several productivity problems importing default exports in my projects. While none of the problems are necessarily impossible to overcome, using named imports and exports seems to better fit my preferences when coding. Making things explicit and leaning heavily on tooling makes me a productive coder, and insofar as named exports help me do that, I will likely favor them for the foreseeable future. Of course, I have no control over how third-party modules I use export their functionality, but I definitely have a choice over how my own modules export things and will choose named exports.
+当我在项目中使用默认导出是，我遇到严重的工作效率问题。然而这些问题并不是无解的，使用命名导出和导入可以更好地配合我的编程习惯。清晰明确的代码和对工具的重度依赖使我成为高效的程序员。只要命名导出可以帮我做到这些，在可预见的未来内，我都会支持它们。当然，我无法决定我用的第三方模块如何导出，但我可以控制我自己写的模块如何导出，我会选择命名导出。


导出是 => 导出时

Fengziyin1234 · 2019-01-25T04:08:13Z

TODO1/stop-using-default-exports-javascript-module.md


-> ES6 favors the single/default export style, and gives the sweetest syntax to importing the default.
+> ES6 偏好单一/默认导出的风格，而且为默认导入提供了甜蜜的语法糖。


甜蜜的语法糖哈哈哈好萌
要不要直接翻译成
更简单的语法

SHERlocked93

@leviding 校对完成

@Hopsken 不错的翻译，学习良多~

SHERlocked93 · 2019-01-25T05:40:33Z

TODO1/stop-using-default-exports-javascript-module.md

 > 
-> Importing a default export has grown to feel like a guessing game where I have a 50/50 chance of being wrong each time. Is it a class? Is it a function?
+> 导入一个默认值感觉上就像抛硬币一样，有一半的概率会猜错。导入的是 class 还是 function？


『导入的是 class 还是 function？』=>『比如有时就搞不清楚我导入的是 class 还是 function。』
后面一句可能直译会比较有歧义，读者也不太明白什么意思，这是我的建议，可以一起讨论下。

SHERlocked93 · 2019-01-25T05:50:39Z

TODO1/stop-using-default-exports-javascript-module.md

 > 
 > — Nicholas C. Zakas (@slicknet) [January 12, 2019](https://twitter.com/slicknet/status/1084101377297506304?ref_src=twsrc%5Etfw)

-I tweeted this after realizing that a lot of problems I had with JavaScript modules could be traced back to fights with default exports. It didn’t matter if I was using JavaScript modules (or ECMAScript modules, as many prefer to call them) or CommonJS, I was still stumbling over importing from modules with default exports. I got a variety of responses to the tweet, many of which questioned how I could come to this decision. This post is my attempt to clarify my thinking.
+我意识到我所遇到的大多数与 JavaScript 模块有关的问题都可以归咎于默认导出，于是就发了这条推特。不管我用的是 JavaScript 模块（或者 ECMAScript，很多人喜欢这么叫它）还是 CommonJS，都会深陷于默认导出的泥潭。那条推特收到了各种各样的评论，很多人都在问我我是如何得出这个结论的。在这篇文章中，我将尽可能地解释我的想法。


『或者 ECMAScript，』=>『或者 ECMAScript 模块，』这里有个 modules 漏译了

『我将尽可能地解释我的想法。』=>『我将尽可能地分享我的思考历程。』因为前文提到了怎么得到的结论，因此这里thinking翻译成想法就感觉不太贴近原意，可以讨论一下

SHERlocked93 · 2019-01-25T06:00:30Z

TODO1/stop-using-default-exports-javascript-module.md


-As is the case with all tweets, my tweet was meant as a snapshot into an opinion I had rather than a normative reference for my entire opinion. To clarify a few points people seem confused by on Twitter:
+正如所有的推文一样，我的推文不过是我的看法的一个缩影，而不是我完整看法的规范性参考。首先我要澄清推文里让人困惑的几点：


『正如所有的推文一样，我的推文不过是我的看法的一个缩影，而不是我完整看法的规范性参考。』=>『正如所有推文一样，我的推文也只是我的个人看法，仅供大家参考。』
这里建议作者斟酌一下，或者大家一起讨论下，根据我个人的理解作者是想表达这个意思，但是原文句子比较复杂

我认为这里的原意就是『因为推文本身长度限制，所以不能完整表达自己完整的想法（由此可能会产生误会）』，然后本文的目的就是详细解释自己的看法，做一些澄清。

SHERlocked93 · 2019-01-25T06:12:39Z

TODO1/stop-using-default-exports-javascript-module.md

-*   The use case of knowing whether an export is a function or a class was an example of the type of problems I’ve encountered. It is not the _only_ problem I’ve found named exports solve for me.
-*   The problems I’ve encountered don’t just happen with files in my own projects, they also happen with importing library and utility modules that I don’t own. That means naming conventions for filenames don’t solve all of the problems.
-*   I’m not saying that everyone should abandon default exports. I’m saying that in modules I’m writing, I will choose not to use default exports. You may feel differently, and that’s fine.
+*   关于不知道导出的是 function 还是 class 这一点，它只是我在使用中所遇到的问题中的一个例子。这不是命名导出为我解决的**唯一一个**问题。


『它只是我在使用中所遇到的问题中的一个例子。』=>『它只是我在使用中所遇到的众多问题中的一个例子。』

SHERlocked93 · 2019-01-25T06:31:26Z

TODO1/stop-using-default-exports-javascript-module.md


-Hopefully those clarifications setup enough context to avoid confusion throughout the rest of this post.
+希望这些澄清设置足够的上下文，以避免在本文的其余部分产生误会。


『希望这些澄清设置足够的上下文，以避免在本文的其余部分产生误会。』=>『希望以上澄清可以避免后文可能产生的一些误会。』
可以讨论一下

SHERlocked93 · 2019-01-25T06:46:54Z

TODO1/stop-using-default-exports-javascript-module.md


-1.  **Explicit over implicit.** I don’t like having code with secrets. What something does, what something should be called, etc., should always be made explicit whenever possible.
+1.  **明了胜于晦涩**。我不喜欢有秘密的代码。某个东西是干嘛的，应该如何调用，诸如此类，在任何可能的情况下，都应该被明确的表示。


『都应该被明确的表示。』=>『都应该明确且清晰。』

SHERlocked93 · 2019-01-25T06:51:06Z

TODO1/stop-using-default-exports-javascript-module.md


-6.  **Cognitive overhead slows down development.** Put simply: the more detail you need to remember to be productive when writing code, the slower your development will be.
+6.  **心智负担会拖慢开发速度**。简单来说，编码时，你需要记忆的用来保证效率的细节越多，你的开发速度越慢。


『心智负担』=>『认知负荷』
可以讨论一下

SHERlocked93 · 2019-01-25T06:58:17Z

TODO1/stop-using-default-exports-javascript-module.md


-## Worse tooling support
+## 糟糕的工具支持Worse tooling support


后面的内容忘了删

SHERlocked93 · 2019-01-25T07:01:01Z

TODO1/stop-using-default-exports-javascript-module.md


-1.  Underline the identifier that is missing its definition and show you the `import` statement that would fix it.
-2.  Automatically add the correct `import` statement (if you have enable auto import) can now automatically add an `import` statement based on an identifier that you type. In fact, WebStorm is able to help you a great deal when using named imports:
+1.  在缺失定义的标识符下加上下划线，显示可以修复这个问题的 `import` 语句。


『这个问题的 import 语句。』=>『这个有问题的 import 语句。』

这里的问题指的是『标识符未定义』

SHERlocked93 · 2019-01-25T07:03:22Z

TODO1/stop-using-default-exports-javascript-module.md


-I’ve had several productivity problems importing default exports in my projects. While none of the problems are necessarily impossible to overcome, using named imports and exports seems to better fit my preferences when coding. Making things explicit and leaning heavily on tooling makes me a productive coder, and insofar as named exports help me do that, I will likely favor them for the foreseeable future. Of course, I have no control over how third-party modules I use export their functionality, but I definitely have a choice over how my own modules export things and will choose named exports.
+当我在项目中使用默认导出是，我遇到严重的工作效率问题。然而这些问题并不是无解的，使用命名导出和导入可以更好地配合我的编程习惯。清晰明确的代码和对工具的重度依赖使我成为高效的程序员。只要命名导出可以帮我做到这些，在可预见的未来内，我都会支持它们。当然，我无法决定我用的第三方模块如何导出，但我可以控制我自己写的模块如何导出，我会选择命名导出。


『使用默认导出是』=>『使用默认导出时』

Hopsken · 2019-01-25T08:13:35Z

@leviding 已根据校对意见修改
@Fengziyin1234 @SHERlocked93 感谢二位的细心校对😁

leviding · 2019-01-25T08:38:57Z

@Hopsken 已经 merge 啦~ 快快麻溜发布到掘金然后给我发下链接，方便及时添加积分哟。

掘金翻译计划有自己的知乎专栏，你也可以投稿哈，推荐使用一个好用的插件。
专栏地址：https://zhuanlan.zhihu.com/juejinfanyi

Hopsken · 2019-01-25T08:59:21Z

@leviding 已发布~ 地址：https://juejin.im/post/5c4acd646fb9a049b5072f0e

Hopsken added 6 commits October 5, 2018 09:58

Merge pull request #1 from xitu/master

14e05af

up to date

Merge pull request #2 from xitu/master

cefaeff

update

Merge pull request #3 from xitu/master

3b48490

sync

Merge pull request #4 from xitu/master

a9aa1a1

update

为什么我不再使用 export default 来导出模块

e05db8f

为什么我不再使用 export default 来导出模块

8a03386

fanyijihua added the 校对认领 label Jan 24, 2019

fanyijihua mentioned this pull request Jan 24, 2019

为什么我不再使用 export default 来导出模块 #5030

Closed

leviding added the 前端 label Jan 24, 2019

fanyijihua added the 正在校对 label Jan 24, 2019

fanyijihua removed the 校对认领 label Jan 25, 2019

Fengziyin1234 previously approved these changes Jan 25, 2019

View reviewed changes

SHERlocked93 reviewed Jan 25, 2019

View reviewed changes

根据校对意见修改

1610b3f

Hopsken dismissed Fengziyin1234’s stale review via 1610b3f January 25, 2019 08:07

添加校对者信息

2f9e41f

leviding added the 标注待管理员 Review label Jan 25, 2019

Update stop-using-default-exports-javascript-module.md

d7da8a1

leviding approved these changes Jan 25, 2019

View reviewed changes

leviding merged commit 304e5a4 into xitu:master Jan 25, 2019

leviding added 翻译完成 and removed 标注待管理员 Review 正在校对 labels Jan 25, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

为什么我不再使用 export default 来导出模块 #5046

为什么我不再使用 export default 来导出模块 #5046

Hopsken commented Jan 24, 2019

Fengziyin1234 commented Jan 24, 2019

fanyijihua commented Jan 24, 2019

SHERlocked93 commented Jan 25, 2019

fanyijihua commented Jan 25, 2019

Fengziyin1234 left a comment

Fengziyin1234 Jan 25, 2019

Fengziyin1234 Jan 25, 2019

Fengziyin1234 Jan 25, 2019

Fengziyin1234 Jan 25, 2019

SHERlocked93 left a comment •

edited

Loading

SHERlocked93 Jan 25, 2019

SHERlocked93 Jan 25, 2019

SHERlocked93 Jan 25, 2019

Hopsken Jan 25, 2019

SHERlocked93 Jan 25, 2019

SHERlocked93 Jan 25, 2019

SHERlocked93 Jan 25, 2019

SHERlocked93 Jan 25, 2019

SHERlocked93 Jan 25, 2019

SHERlocked93 Jan 25, 2019

Hopsken Jan 25, 2019

SHERlocked93 Jan 25, 2019

Hopsken commented Jan 25, 2019

leviding commented Jan 25, 2019

Hopsken commented Jan 25, 2019


		6. Cognitive overhead slows down development. Put simply: the more detail you need to remember to be productive when writing code, the slower your development will be.
		6. 心智负担会拖慢开发速度。简单来说，编码时，你需要记忆的用来保证效率的细节越多，你的开发速度越慢。


		## Worse tooling support
		## 糟糕的工具支持Worse tooling support


		I’ve had several productivity problems importing default exports in my projects. While none of the problems are necessarily impossible to overcome, using named imports and exports seems to better fit my preferences when coding. Making things explicit and leaning heavily on tooling makes me a productive coder, and insofar as named exports help me do that, I will likely favor them for the foreseeable future. Of course, I have no control over how third-party modules I use export their functionality, but I definitely have a choice over how my own modules export things and will choose named exports.
		当我在项目中使用默认导出是，我遇到严重的工作效率问题。然而这些问题并不是无解的，使用命名导出和导入可以更好地配合我的编程习惯。清晰明确的代码和对工具的重度依赖使我成为高效的程序员。只要命名导出可以帮我做到这些，在可预见的未来内，我都会支持它们。当然，我无法决定我用的第三方模块如何导出，但我可以控制我自己写的模块如何导出，我会选择命名导出。


		> ES6 favors the single/default export style, and gives the sweetest syntax to importing the default.
		> ES6 偏好单一/默认导出的风格，而且为默认导入提供了甜蜜的语法糖。


		As is the case with all tweets, my tweet was meant as a snapshot into an opinion I had rather than a normative reference for my entire opinion. To clarify a few points people seem confused by on Twitter:
		正如所有的推文一样，我的推文不过是我的看法的一个缩影，而不是我完整看法的规范性参考。首先我要澄清推文里让人困惑的几点：


		Hopefully those clarifications setup enough context to avoid confusion throughout the rest of this post.
		希望这些澄清设置足够的上下文，以避免在本文的其余部分产生误会。


		1. Explicit over implicit. I don’t like having code with secrets. What something does, what something should be called, etc., should always be made explicit whenever possible.
		1. 明了胜于晦涩。我不喜欢有秘密的代码。某个东西是干嘛的，应该如何调用，诸如此类，在任何可能的情况下，都应该被明确的表示。

为什么我不再使用 export default 来导出模块 #5046

为什么我不再使用 export default 来导出模块 #5046

Conversation

Hopsken commented Jan 24, 2019

Fengziyin1234 commented Jan 24, 2019

fanyijihua commented Jan 24, 2019

SHERlocked93 commented Jan 25, 2019

fanyijihua commented Jan 25, 2019

Fengziyin1234 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SHERlocked93 left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Hopsken commented Jan 25, 2019

leviding commented Jan 25, 2019

Hopsken commented Jan 25, 2019

SHERlocked93 left a comment •

edited

Loading