ecomfe / spec

This repository contains the specifications.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[esnext] “所有import语句写在模块开始处”的说明是错误的

hax opened this issue · comments

“import会被默认提升至模块最前面”这个说法是错误的,实际并不会。

“浏览器如能尽早读取相关的import内容则有可能更早地请求相关的依赖模块,有一定的性能提升作用,在HTTP/2之后可能会具有更明显的效果。”——这些说法也存疑,虽然理论上似乎是可能的。实际上更可能的是服务器端利用HTTP/2在没有请求的情况下预先发出被依赖的module——然而此种优化与import的前后并无关系。

另外bad的代码本身是错误的,import语句只能在top-level,而不能在函数里。

那么 @hax 本身赞成import均写在文件最前这个方式吗

@otakustay

我个人试验过就近import的写法(写在第一个需要此导入的函数之前,例子 https://github.com/baixing/jedi/blob/master/src/transform/import.js ),其实也还行,主要的问题在于 import 是不能重复的,意味着你其实无法就近写出所有的依赖。此外因为只能在top-level所以在函数体比较大的情况下也不能做到真正的就近(反而是commonjs的require可以真正就近)。

我的感觉是:如果模块足够小和内聚,当然全写在模块顶部是很ok的。
问题可能出在比较复杂的模块,比如api入口文件(facade模式)。这时就近import有助于在阅读单一功能时更快看清楚依赖。然而这也许是模块需要进一步拆分的信号。

总的来说,我略微倾向于全写在最前面。

印象中 C , JAVA 都是在文件 top import 吧

是的,我理解它们将import作为一个源码的meta信息看待

在 2015年11月12日,下午1:22,Phinome notifications@github.com 写道:

印象中 C , JAVA 都是在文件 top import 吧


Reply to this email directly or view it on GitHub.

commented

@otakustay 改改说明?

commented

根据 @hax 阐述的

因为只能在top-level所以在函数体比较大的情况下也不能做到真正的就近(反而是commonjs的require可以真正就近)。

以及与 @otakustay 的讨论,既然做不到就近,其他语言都是top import/include/using,那就挺自然的,没什么解释的必要了。所以将解释部分直接删除。