はじめに
- この記事は修正版です。教えて頂いた方々ありがとうございます
- 無名関数でdefault exportしてコンポーネントを定義することが、ポジティブな便利機能のようにも受け取れる文章だったので全体的に修正しております
問題
- 極論、以下のようにしても動作してしまい、以下のようなデメリットがある
// prj-name/src/components/DefaultExportComponentExample.jsx
export default () => {
const funcname = () => {何らかの処理}
return (
<>
<p>hogehoge</p>
</>
)
}
// 呼び出し側
import AnotherNameHogehogeComponent from './components/DefaultExportComponentExample'
function App() {
return (
<>
<div>
<AnotherNameHogehogeComponent />
</div>
</>
)
}
export default App
解決
- コードレビューなどで発見すれば指摘して修正する
- 静的解析に必要なルールを導入する [react/display-name]
終わりに
- 新規にプロジェクトを立ち上げて静的解析確認したところ、無名関数で定義したコンポーネントについてはデフォルトで入っているルールで警告されました(Vite + React19 + JavaScript環境)
- 実験して色々再現しようと思ったが、すぐに思い付かず。ただ軽く調べる限りでも「ありそうだな」と思える苦しさがたくさん出てきたのでよくなさそう。Default Exports in JavaScript Modules Are Terrible という記事を書く方もいるようだ
Before considering how this would be imported and used, I would like to point out another problem that can affect the developer experience too. The exported member is the default for the module. It is essential to consider the impact of this. Why is subtract a default, but add is a named export? Perhaps this artificial example does not highlight this problem well.
- いつかtree shakingも実験したい
変更履歴
v1
【React】default exportなら無名関数でコンポーネント定義できるはじめに
- たまたまIDEのコード補完で見つけた
- こういうのを一つ一つ拾ってアウトプットしていると色んな事と繋がって覚えられて良い
内容
- 以下のように定義できる
- default exportなので当然使う側で名前を決められる
- ただ、名前空間を決める恩恵があるのでnamed exportの方が使う機会は多そう。一つ階層構造にあそびがあるのがnamed exportの勝っている点かと
export default () => {
const funcname = () => {何らかの処理}
return (
<>
<p>hogehoge</p>
</>
)
}
終わりに
- default exportはあくまでデフォルトだから、フォールバックして一意に定まる感じなのかなと思った
- Laravelのシングルアクションコントローラーとか好きな人もいるし、読めて損はなさそう
- named export, default expoertという名前の通りでやっぱり命名は大切だと思った

