今日のタブ記事2つ

昨日の夜オワっていたので今日になりました。

今日のタブ記事

まさにこのサイトと同じような用途でNext.jsを使っていたので参考になる。

日付がないのでいつ頃の記事かはわからないけど、VercelじゃなくてZeitって言ってるからわりと前かも。

markdownのサーバーサイドレンダリングの話で、markdown-itというライブラリを使っているとのことらしい。このサイトではマークダウンのパースはgray-matterというやつを使っていて(Next.jsのドキュメントに出てくるやつをそのまま使った)、パースはするけどスタイルの定義は独自で当てているため、カスタマイズが容易っぽいこのmarkdown-itというやつは気になる。

シンタックスハイライトもhighlight.jsを使うと便利そう。いちいち見た目のCSSを頑張って書いていたけど、最初からこういうやつを使えばよかったな……。

gatsbyはカタログスペックはよかったんだけど、なんか直感的にこなれてなさを感じて避けた。 gatsby new で生成されたディレクトリの雑然さから、学習コストの割に得るもの少なそうな気配を感じ取った。一方でNext.jsは初見の洗練されてる感がすごくて心を持っていかれた。(引用)

わかるな〜〜〜〜〜

今日のタブ記事その2

経年劣化に耐える ReactComponent の書き方

普段Vue/Nuxt書いてるけどReactのほうが好きなのでReactの記事のほうが読んだり調べたりする率が高い。

TakepepeさんはReactの話でよく名前を見る有名な方っぽいなと思っているので、いつも勉強になりますという気持ちで読んでいます。

経年劣化に耐えるというフレーズは個人的に惹かれるものがあり、「コードは書いた瞬間から負債化する」というのを聞いたりしていてまあそうだよなと思っていたので、負債になることを避けるというより負債になったらすぐ捨てれるor負債化の被害が少ないコードを書いていきたいという思いが常にあるため、この記事はいいな〜と思った(当時開いた自分はたぶんそういう感じのことを思っていたのだと思う)

VueのSFCのような形で「どの順番で何を書くか」を分ける形でReactのコンポーネントを記述する、ということらしい。

例のコードをそのまま引用させてもらうと、

// (1) import層
import React from 'react'
import styled from 'styled-components'
// (2) Types層
type ContainerProps = {...}
type Props = {...} & ContainerProps
// (3) DOM層
const Component: React.FC<Props> = props => (...)
// (4) Style層
const StyledComponent = styled(Component)`...`
// (5) Container層
const Container: React.FC<ContainerProps> = props => {
  return <StyledComponent {...props} />
}

記述順は大切で、「依存関係の上流下流」に従うらしい。つまり下のほうにあるコードほど上のコードに依存しているということだろう。

3のDOM層はReactに限らず他のライブラリでも使用される技術なのでReact依存のhooks APIを除くためにreturn文を必要としないconst Component = props => (...)の記法を用いるらしい。なるほど……。

こうすることでstateの存在しない真にstatelessのコンポーネントになる。たしかに。テストのしやすさもこれで担保してるのか、すごい。

4のStyle層でスタイルをつけていて、ここではstyled-componentsを使っているけどCSS Modulesに替えても成立する記法らしい。でもCSS Modulesってコンポーネントファイルで.module.cssをimportしてクラス名をつけていくイメージだったんだけど、この層でいけるのかな？

5のContainer層に関しては分かりやすくて、hooksを含めたロジックをこっちに置いて関心を分離しているというのが分かる。この層の分け方めっちゃいいな〜。

PresentationalComponent/ContainerComponentの分け方はhooksが隆盛な今でも踏襲すべきベストプラクティスである、と言ってて、普段Reactを書かない自分でもあの分け方はいいなと思っていたのでこう言ってもらえてよかったと思う。依存の注入を行う層ということで、やはりDOM層と分けると分かりやすいな。

ここで「賢いコンポーネント」作っておくことでモック化しやすくてテストしやすい、依存技術を変える際も変更箇所が分かりやすい、などなど色々あって「最高……」となった。

コメント欄にもなにげにいいことが書いてあってので書いておくと、

Container層が必要ないコンポーネントは4層になってロジックがほぼないコンポーネントになる
Style層が深くなったときにはコンポーネント分割の合図
- 具体的には、 > を二つまでくらいが見通しのいいコンポーネントと言えそう
そもそも > を使うと意図しないスタイルが当たる
- なので、buttonなどの要素をラッパーに内包するか、そもそも > button のような曖昧な指定をしないようにする

めちゃくちゃ勉強になった。