default export と named export
default export を使わず named export を使ったほうがいいなという話になり、自分なりに考えてみたんだけど、色々な記事が出ていたのでそれらも参考にした。
自分としては、
- リファクタリングをする際に export で行っている処理を変えた場合、 default export だと import 側では命名を変更する必要がないため、古い実装に合わせた命名のままになってしまう
- named export であればエディタが怒ってくれる
くらいしかぱっと出てこなかったのだけど、いくつか記事を読んで色々知ることができた。
Avoid Export Default - TypeScript Deep Dive 日本語版
TypeScript Deep Dive のページだと、
- オートコンプリートがある
- default export だと、複数箇所で import するときに命名がバラバラになったり typo したりする
- named export で export する命名を変更したとき、 import の名前も自動で修正される
あたりが named export を使うほうがいい主な理由として書いてあった。
なぜ default export を使うべきではないのか？
default export は CommonJS 時代の module.exports を彷彿とさせる仕様であり、考えることも少なく便利な仕様であるはずです。
事実私も default export を頻繁に利用していましたが、大きな2つの課題によって named export のみを許容するようになりました。
それは課題がリファクタリングのしやすさとエディタとの親和性という、プロジェクトの生産性に影響を及ぼすものであったからです。
とあるように、昔は default export を便利に使っていたが変わってきたという感じだと思う。自分も昔は default export を使っていたような気がする。
default export だと、 import 側で命名が自由に決められることを良くないことだと捉え、リポジトリが大きくなっても変化に強い状態であると言えそう。
そしてエディタの補完の効果が最大限発揮されるのも named export だという。
ただし、どうしても命名が被ってしまう場合を除いて as は極力使わないようにする(これも命名を自由に決めることに他ならないので)のと、ファイル名を明確なものにするという注意点がある。
アンサー: named exportは有害なのか - uhyo/blog
named export 否定派の記事もあり、またそれに対する uhyo さんのアンサー記事もあった。
これらを読んだら、 default export と named export の良し悪しの話もそうだが、議論の前提の整理と、それにより問題としている部分を整理することの大事さを学べたような気がする。
自分と異なる意見は当然に下等・幼稚なものであるというのは筆者が最も嫌う考え方ですから、このような異なる意見を分析・理解する必要があると思い、アンサー記事という形でまとめました。具体的には、異なる意見に達する理由としては前提が異なることと論理が異なることが主に挙げられます。前提が異なることが分かれば、自分と異なる意見に至った理由を理解でき、場合によっては取り入れることもできます。論理が違うのであれば、それは瑕疵であり指摘しなければいけません。
なお、そもそも「named export/default exportの違いは些細なものでありこだわるべきではない」といった視座の高い意見も見られますが、考察を避けるためにそのような意見を発することには筆者はそれには賛同しません。確かに細かいことではありますが、こういった細かい考察の積み重ねがクオリティの高いコードを書く能力につながると考えているからです。人が言っているものを無条件に受け入れる態度は必然性に欠けるので高いクオリティに繋がりにくいし、ときにこのような矛盾に直面してしまいます。自分の前提を持ち自分で考察して決めるか、もしくは各主張の前提を理解し自分の前提と合致するものを取り入れるというのが理想的な状態だと考えます。論理的に考えてどちらでも良いという結論に至ってから初めて、こだわるべきではないと言うことができるのです。
これらの言葉は非常に刺さるものだった。自分で考え、自分で調べ、自分で決めた考えを持つことで、他の主張を理解し、受け入れ、意見することができるんだなあ。もっと自分で意見を持てるようにしたい。