遅ればせながらこの前の年末年始に Tailwind CSS と Chakra UI を触った。（月並みな感想だが） utility-first CSS は書きやすい一方、前者は class に書かれる多くのユーティリティによりノイズが多く見え、後者は別の機能が載りすぎて too much という印象を受けた。これらを眺めていると、全てのスタイルを class や Props に直接は書かなくても utility-first CSS の利点を生かせるのではないかと思い始めた。
この記事では、Tailwind CSS との互換機能を持つ Windi CSS[1] を利用しつつ、utility-first CSS におけるノイズの少ない表記法として、配置用ユーティリティだけ使う場合の例を示す。
製品のフロントエンドで利用する「UI システム」を漸進的に移行していく際に役立ちそうな方法を思いついて組んでみた。残念ながら自分はこの方法は当面使わないことにしたので、ある種の小ネタ集として公開し、供養しておく。
イベントハンドラって渡されなくてもそのコンポーネントは困らないよなということで、React においてもタイトルの書き方をこれからはやっていきたいという気持ちを表明しておく。
以前の記事で View-Hook Pair というものを提案した。今回はこれを用いでバリエーションのあるコンポーネントをどう実装できるかについて述べる。この方法を使うと、仕様変更やリファクタリングのしやすさを大きく損なわない形でコードの共通化を実現できる。
複雑なアプリケーションのためにストアが肥大化したり乱雑化したりしていたところと付き合ってきて、今後もこれではかなり厳しくなっていくからどうにかしたいという気持ちになった。
この記事ではこれを整理するため、また、他のエンジニアが考える中でも「余計な」検討をせずに済むように、コンポーネントから API アクセスまでの領域に構造を導入することで、それらを分離して絡まりを幾分ほぐせるようにしたい。
タイトルのような React 設計の提案を思いついたが、文脈・問題やほかの方法との比較、良し悪しを詳細にしようと書いていたところ時間がかかりすぎ、いつまで経っても手法を公開できず機を逸しそうだったため、先に手法だけ公開しておこうと思う。動くサンプルプロジェクトも何もない。
大きい処理について、サーバーやツールではレイヤーや関心単位により比較的簡単に分割できるが、フロントエンドのコンポーネントでは別の難しい問題がある。それに対して View-Hook Pair と名付けた分割統治方法を（軽く）提案する。
これは 設計ナイト2020 の感想記事です。
CQRS と GraphQL の話が主な話題でしたが、ディスカッションなどで示唆に富む話を聞けたので、（レポートというよりも）考えたことを書き残しておきます。
発表内容についてはあまり書きませんが、すでに 設計ナイト2020感想 - Qiita と 設計ナイト2020に参加してきました。 | achanBlog という記事があります。 Q&A やディスカッションについても #sekkeinight 付きのツイートを見ると、何が交わされたか把握できると思います。
TypeScript に Template literal types というかなりヤバい革新的な新しい機能の PR が出された。
Template literal types and mapped type ‘as’ clauses
体を慣らすのを兼ねて簡易 Lisp パーサーを型上で実装してみた。正直なところ Lisp でプログラミングはほぼしないが、文法が簡単に見え Template literal types で処理できそうだったため若気の至りでやってしまった。さすがに実行はできない（数値演算が無理ゲー）。意外と Lisp が興味深い言語に感じた。
有名どころの Lisp 派生言語の共通項を実装すると実装時間がやばそうなので、構文は最小限にした。
[Try it on the Playground] -> Parse<`'(try your code)`>