Avoid Export Default
export default
は有害だと考えられます
export default
は有害だと考えられます以下の内容のfoo.ts
ファイルがあるとします:
次のように、ES6構文を使用して(bar.tsで)インポートします。
これには保守性の問題がいくつかあります:
foo.ts
でFoo
をリファクタリングしても、bar.ts
では名前が変更されませんfoo.ts
(これはあなたのファイルの多くが参照しているものです)から、より多くのものをexportする必要がある場合、import構文をいじくる必要があります。
このため、私はシンプルなexports + 分解importを推奨します。例: foo.ts
:
そして:
下にもいくつかの理由を書きます。
CommonJSとの相互運用
default
は、const {Foo} = require('module/foo')
の代わりに、const {default} = require('module/foo');
を書かないといけないCommonJSユーザーにとって、恐ろしい体験になります。あなたはたいていdefault
エクスポートをインポートしたときに他の何かにリネームすることになるでしょう。
低い検出性(Poor Discoverability)
デフォルトエクスポートは検出性(Discoverability)が低いです。あなたはインテリセンスでモジュールを辿り、それがデフォルトエクスポートを持っているかどうかを知ることができません。
デフォルトエクスポートでは、あなたは何も得られません(それはデフォルトエクスポートを持っているかもしれませんし、持っていないかもしれません¯\_(ツ)_/¯
):
デフォルトエクスポートが無ければ、素晴らしいインテリセンスが得られます。
オートコンプリート(Autocomplete)
エクスポートについて知っているか、いないかに関わらず、あなたはカーソル位置でimport {/*here*/} from "./foo";
をオートコンプリートできます。それはデベロッパーに少しの安心感を与えます。
タイポに対する防御(Typo Protection)
あなたはimport Foo from "./foo";
をしながら、他でimport foo from "./foo";
をするようなタイポをしたくないでしょう。
TypeScriptの自動インポート
自動インポート修正は、うまく動きます。あなたがFoo
を使うと、自動インポートはimport { Foo } from "./foo";
を書き記します。なぜなら、それはきちんと定義された名前がモジュールからエクスポートされているからです。いくつかのツールは、魔法のようにデフォルトエクスポートの名前を推論します。しかし、風変わりな魔法です。
再エクスポート(Re-exporting)
再エクスポートは不必要に難しいです。再エクスポートはnpmパッケージのルートのindex
ファイルで一般的に行われます。例:import Foo from "./foo"; export { Foo }
(デフォルトエクスポート) vs. export * from "./foo"
(名前付きエクスポート)
Dynamic Imports
デフォルトエクスポートは、default
を動的にインポートしたときに、それ自身に悪い名前を付けます。例:
非クラス/非関数の場合、2行必要です
関数/クラスに対しては、1行で書けます:
名前が無い/型アノテーションされたオブジェクトに対しても、1行で書けます:
しかし、他のものに対しては2行必要です:
最終更新