書く日が毎日ではなくバラバラなので当日起きたことではないことも書きます。

スプレッド演算子を使ってpropsを渡すのって……？

最近盛り上がっているKuma UIの作者のpoteboyさんがこんなツイートをしていた。

propsをスプレッド構文で渡すのはとても便利で僕もよくやるけど、ビルド時の最適化ができなくなるのでKumaでは非推奨(そしてこれはMillion.jsでも同様)。コンパイラに優しいコードを書く必要がある。

— 𝗉𝗈𝗍𝖾𝖻𝗈𝗒 (@_poteboy_) July 20, 2023

自分は全くこんなことを考えてなかったので、そうなの！？と思ってびっくりしたので数日後になったがリプライで「これについての記事やドキュメントってありますか？」と聞いてみた。

すいません見落としてました🙏
いえ、特にありません！ビルド時にコンポーネントの最適化を測る類のライブラリと相性が悪いという程度なので、普段使う分には全く気にする必要無いと思われます！

— 𝗉𝗈𝗍𝖾𝖻𝗈𝗒 (@_poteboy_) July 25, 2023

こんな感じのお返事をもらった。

ビルド時にコンポーネントの最適化を行うライブラリ、一切の知識がないのでどんな感じか分かっていないので知識不足だなと思いつつ、poteboyさんは普段使うぶんには気にしなくてもいいということを教えてくれたので、そのまま使おうと思います。

実際にみんなスプレッド構文で渡すprops使ってるのか……？

自分はよく使っていて、

const Post: React.FC<Post> = ({ id, title, description, author }) => {
  // ...
  return (
    <>
      <div>{title}</div>
      <div>{description}</div>
      <Author {...author} />
    </>
  )
}

みたいな書き方をする。

この書き方って実際みんなどうしているんだろうか？

↑の例だとまあ多少分かりやすいかなと思うんだけど、例えばNext.jsのpagesコンポーネントから下の階層にpropsを渡すときみたいな大量のpropsがある場合はどうか。

propsを渡す部分の書く量がかなり減るとは思うんだけど、ぱっと見たときにどんな値をpropsとして渡しているのかは分かりにくくなると思う。

TypeScriptを使っている前提だと、型定義は当然そのページに存在すると思うのでそれを参照すればいいと思うんだけど、この場合どっちのほうがいいんだろうか。

また、スプレッド演算子で渡すので当然プロパティの名前は渡す側が渡される側に合わせないといけないので、ちょっと渡すデータを加工したりすることになったとき若干めんどうかもしれない(プロパティ名が違うものだけ個別で渡して残りをスプレッド演算子にすればいいというのはあるけど)

これみんなどうしてるんだろう。派閥があったりするのかな。propsにスプレッド演算子を使わないようにする/使える場合それを指摘するESLintとかもあるんだろうか。