製品のフロントエンドで利用する「UI システム」を漸進的に移行していく際に役立ちそうな方法を思いついて組んでみた。残念ながら自分はこの方法は当面使わないことにしたので、ある種の小ネタ集として公開し、供養しておく。
イベントハンドラ Props は optional にする
イベントハンドラって渡されなくてもそのコンポーネントは困らないよなということで、React においてもタイトルの書き方をこれからはやっていきたいという気持ちを表明しておく。
View-Hook Pair によるバリエーションのあるコンポーネントの実装
以前の記事で View-Hook Pair というものを提案した。今回はこれを用いでバリエーションのあるコンポーネントをどう実装できるかについて述べる。この方法を使うと、仕様変更やリファクタリングのしやすさを大きく損なわない形でコードの共通化を実現できる。
フロントエンドではまずプレゼンテーション系を分離する
複雑なアプリケーションのためにストアが肥大化したり乱雑化したりしていたところと付き合ってきて、今後もこれではかなり厳しくなっていくからどうにかしたいという気持ちになった。
この記事ではこれを整理するため、また、他のエンジニアが考える中でも「余計な」検討をせずに済むように、コンポーネントから API アクセスまでの領域に構造を導入することで、それらを分離して絡まりを幾分ほぐせるようにしたい。
View-Hook Pair パターン（草案）
タイトルのような React 設計の提案を思いついたが、文脈・問題やほかの方法との比較、良し悪しを詳細にしようと書いていたところ時間がかかりすぎ、いつまで経っても手法を公開できず機を逸しそうだったため、先に手法だけ公開しておこうと思う。動くサンプルプロジェクトも何もない。
大きい処理について、サーバーやツールではレイヤーや関心単位により比較的簡単に分割できるが、フロントエンドのコンポーネントでは別の難しい問題がある。それに対して View-Hook Pair と名付けた分割統治方法を（軽く）提案する。
技術系の境界線
これは 設計ナイト2020 の感想記事です。
CQRS と GraphQL の話が主な話題でしたが、ディスカッションなどで示唆に富む話を聞けたので、（レポートというよりも）考えたことを書き残しておきます。
発表内容についてはあまり書きませんが、すでに 設計ナイト2020感想 - Qiita と 設計ナイト2020に参加してきました。 | achanBlog という記事があります。 Q&A やディスカッションについても #sekkeinight 付きのツイートを見ると、何が交わされたか把握できると思います。
Template literal types で型上の簡易 Lisp パーサー
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)`>
ユーザーも DevOps の範疇だ
春から新しい職場で働いているが、Web 系の仕事かつエンタープライズに近いという点は前の職場とも共通している（次を探すときも似た条件になるんだろう）。今の職場のリリースサイクルは速いので良いと思う。
働く中で「リリースしやすさ」についていろいろ思い浮かんだことがあるので、明文化して残しておこうと思う。