昨日の夜オワっていたので今日になりました。
今日のタブ記事
まさにこのサイトと同じような用途で Next.js を使っていたので参考になる。
日付がないのでいつ頃の記事かはわからないけど、Vercel じゃなくて Zeit って言ってるからわりと前かも。
markdown のサーバーサイドレンダリングの話で、markdown-itというライブラリを使っているとのことらしい。このサイトではマークダウンのパースはgray-matterというやつを使っていて(Next.js のドキュメントに出てくるやつをそのまま使った)、パースはするけどスタイルの定義は独自で当てているため、カスタマイズが容易っぽいこの markdown-it というやつは気になる。
シンタックスハイライトもhighlight.jsを使うと便利そう。いちいち見た目の CSS を頑張って書いていたけど、最初からこういうやつを使えばよかったな……。
gatsby はカタログスペックはよかったんだけど、なんか直感的にこなれてなさを感じて避けた。 gatsby new で生成されたディレクトリの雑然さから、学習コストの割に得るもの少なそうな気配を感じ取った。 一方で Next.js は初見の洗練されてる感がすごくて心を持っていかれた。
わかるな〜〜〜〜〜
今日のタブ記事その 2
普段 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
のような曖昧な指定をしないようにする
- なので、button などの要素をラッパーに内包するか、そもそも
めちゃくちゃ勉強になった。