バックエンドエンジニア、異世界転生してフロントエンドエンジニアになる！第一話「React気持ち悪い！」

変数がページの形態と連携する(useState)という、一見スマートに見えるReactの仕様。しかしページに複数の形態をもたせることで、二つの仕様について「二つのページに分けるべきなのか」「二つの形態を持った一つのページで良いのか」という疑問が発生する。これはファイルストラクチャ（フォルダとファイルを使った情報格納）に基づいてページが生成されるというReactの特徴に真っ向から歯向かうような設計である。更に、この設計が故にページに表示される内容に関わる変数は「変数」ではなく「固定数」であり、その内容を変えるためにはページを完全に再生成する関数を使用しなければならない、というギミックじみた仕様になっている。
Reactのフレームワーク外に関する処理（ビデオプレイヤーなど）やDOMエレメントに対する働きは専用のuseEffectやuseRefという関数や変数（というかタグ？アトリビュート？）を使用して行うことにも違和感がある。というのも、もしReactがフレームワークなのであれば、フレームワーク外の処理を行うことは極めて稀なことであるべきだ。JSX記法が主流になりつつある今、純粋なReactのフレームワークの外にあるものに対してはReactフレームワーク内にそれと連携するインターフェイスくらい準備していてもいいと思うのだが、全くその方向で考えずにuseEffectやuseRefという「フレームワークからエスケープしてコードを実行する」方向性でuseEventEffectなどを実装し始めているのを見ていると設計思想を疑わざるを得ない。
こういった特徴を持ちながらもドキュメンテーションでは「従来のJavascriptとは違い、宣言型プログラミングが可能」と謳っているのがさらなる混乱を招く。上にも書いたが、ページに形態が存在し、それがユーザーの入力またはサーバー側のロジックによって変わる、というのはまさしくそのページを使用することによるプログラム全体への「副作用」があるということになり、宣言型プログラミングから逸脱することになる。確かにuseStateやuseEffect, useRefを使わなければほぼ宣言型になるのだろうが、現実的にそれが不可能（トグルを一つ加えただけでuseStateを使わないといけなくなる）のは設計としてどうなんだろうか。
例えば、仮に「ダークモードとライトモードを実装する」となった時に、トグルボタンとuseStateのような実装をせずに、クッキーにダークモードまたはライトモードの情報を書き加え、ページをリロードし、クッキーの情報をもとにサイトが生成されれば良いのではないか。またそれをもっとreactiveにしたいのであれば、別に宣言型プログラミングのパラダイムから逸脱してuseStateなど使わずにページに対して必要な変更をまとめて加える関数を呼び出すボタンとして実装すれば良い。
ということで、あまりに設計として納得が行かないのでフロントエンドの開発をするにあたって余計なステートを加えないように注意して行きたいと思う。