Remix3 (Remix Jam 2025)について
Remix3について書いてみます。
1) Remix.Handle.render、Remix.Handle.update
Remix3では、コンポーネントのレンダリング・再レンダリングのマニュアル(手動)でのコントロールを可能にしています。
Remix開発チームがPreactからフォークして開発中のライブラリ(Preactフォーク)がまだ公開されるレベルになっていないため、想像にすぎませんが、これらのメソッドは、Preactフォークの内部で呼ばれることになるはずです。
リリース版Remix3では、Remix.Handle.render、Remix.Handle.updateをユーザーが直接記述する機会は少なくなるはずです。
2) Remix.Handle.context
contextでの取り回しにProviderコンポーネントをかますことが必須のReactのcontextとは違い、RemixのcontextはVue.js3のprovide/injectライクにset/getで取り回しができます。
domパッケージ(モジュール)の機能として提供されています。
Preactフォークでは、利便性のために、Remix.Handle.contextへのエイリアス？が提供されるかもしれません。
3) セットアップスコープ
Remix3では、コンポーネントに記述されたステート(状態)の保持は、このセットアップスコープによって行われます。
Remix3では、コンポーネントはクロージャとして扱われます。
Remix3の中でコンポーネントは一度クロージャとして実行され、実行結果が(内部変数に)格納/保持され、(同一コンポーネントから)参照可能で、関数であるのに恰もオブジェクトであるかのように扱えるようになっています。
セットアップスコープでは、ステートはミュータブル(mutable: 可変)な値として扱われます。
Remix3では、ReactやPreactベースのFW(フレームワーク)とは異なり、(セットアップスコープの段階では)ステートはミュータブル(mutable: 可変)な値として扱われます。
Preactフォークで、ステートがミュータブルな値として扱われるのか、イミュータブル(immutable: 不変)な値として扱われるのか、は不明です。
ステートの保持(自体)は(Preactフォークからは独立した)セットアップスコープで行うため、Preactフォークでステートがミュータブルな値として扱われる(＆リアクティビティが提供されない)場合、Preactフォークに(ステート保持機能の実装は必要ないので)ステート管理機能(API)が存在しない可能性は高いです。
4) dom、events ...モジュール
Reactではreact-domパッケージがDOM API etcをカプセル化(隠蔽)していて、Reactの(抽象化された)インターフェイス(API)を介してしかDOM API etcにアクセスできないのに対して、Remix3はDOM API/イベントetcが独自のインターフェイス(API)をもつモジュールとなっていて、それぞれにアクセス可能となっています。
Preactフォークは、Reactのように内部にイベントやレンダリングetc全てを内包するのではなく、イベントまわりはevents、DOMまわりはdom、他もそれぞれ別モジュール？、として(別に)存在し、Preactフォーク(自体)はそれらのモジュールを内部で利用する(Reactとは異なり)かなり？コンパクトなライブラリになると考えられます。
Remix3では、特定のライブラリに強く依存しない方針なので、自前で用意するPreactフォークにさえ強く依存しないしくみにしようとしているのかもしれません。
5) Preactフォークでのステートの扱い＆リアクティビティ
Preactフォークがステート(状態)管理のAPIを提供しないのか、PreactデフォルトのReactライクなステート管理APIを採用するのか、Preact SignalsのようにSignalsを採用する(Preact Signalsもどき？を統合する？)のか、はたまた、第3のステート管理用APIを採用するのか、定かではありません。
リアクティビティについても同様で、リアクティビティ自体、採用しないのか、(Reactライク？の)Preactライク？なリアクティビティを採用するのか、Signals(ライクな？リアクティビティ)を採用するのか、定かではありません。
何らかのリアクティビティが採用される場合、リアクティビティとステートを関連づける(ステートの変更を追跡する)ために、ステート管理のAPIが必要になります。
Remix3では、ステートの保持はセットアップスコープが担当するので、Preactフォークでステート管理のAPIが提供される場合、それはReactともPreactとも似て非なるモノです。
現状のプロトタイプ？をAlien Signalsと組み合わせて利用しても面白いかと思います。
6) URL/リソースベース・ルーティング
プロトタイプでは、URL/リソースベース・ルーティングが用意されています。
ルーティングは@remix-run/fetch-routerモジュール(のAPI)を用いて記述します。
(Railsライクに)(HTTPの)GETだけではなくPOST/PUT/DELETEも扱います。
WEB標準重視なので？(Reactのような)JSX/TSX(上)でのformのaction(属性)と(コンポーネント(内)/サーバー(/リモート)の)関数の直接の紐づけは、(今のところ)行えません。
ルーティング定義
demoアプリのルーティング定義まわりを読み解いて？みます。
ルーティング定義のロジック内で、formAction関数にパス(ルートハンドラグループ名(+α))を渡し取得した返値をリソース名と対にすることで、リソース名とルートハンドラグループを紐付け、ルートハンドラグループ内のハンドラ(関数)をURL(パス)で呼び出せるようになります。
ルートハンドラグループ(ルートハンドラズ)は、一覧表示？のindexプロパティ、詳細表示のshowプロパティ、formのactionに対応するactionプロパティ、POSTに対応するcreateプロパティ、PUTに対応するupdateプロパティ、DELETEに対応するdestroyプロパティ、etc(のRESTに対応するプロパティ)を(任意で)内包します。
プロパティには、HTTPのメソッドとURLのパターンをセットしたオブジェクト or 関数(ハンドラ) etc?をセットできます。
JSX/TSXでは、formのaction属性にルートハンドラに対応するURL(パス)をセットすることで、formのactionとルートハンドラの紐付けを行えます。
WEB APIとリソース名の紐付けはroute関数にパス(URL)とルートハンドラグループ名を渡して取得値をリソース名と対にすることで行えます。
route関数に渡すルートハンドラグループのプロパティに、formAction関数に、パス((別の)ルートハンドラグループ名(+α))と、HTTPのメソッドと(別の)ルートハンドラグループ内の(外部公開する？)ハンドラ名(複数指定可能)をセットしたオブジェクトを渡して取得した返値をセットすると、対応するルートハンドラグループ内の関数(ハンドラ)をURL(パス)で呼び出せるようになります。
このようにして、ルートハンドラグループから別のルートハンドラグループのプロパティ(ハンドラ)を参照します。
複数リソースを扱う場合には、WEB APIとリソース名の紐付けは、route関数の代わりにresources関数を用いて、対応するハンドラグループ名と(外部公開する？)プロパティ(ハンドラ)名(ハンドラグループ内)を記述したオブジェクトを渡すことで、対応するハンドラグループ内の関数(ハンドラ)をURL(パス)で呼び出せるようになります。
リリース版Remix3では、簡潔に書けるようになるはずです。
リリース版Remix3では、URL/リソースベースルーティング に加え、ファイルベースルーティングも提供され、併用が可能になることに期待しています。
7) Preactフォークは仮想DOMを採用する？
ブラウザ(のレンダリングまわり(タイミングを含む))の実装の改善により仮想DOMがパフォーマンス上の優位性をなくし役割を終えようとしています。
Remix v3に採用されるはずのPreactフォークが仮想DOMをPreactから引き継ぐのか、仮想DOMから離脱しSolid.jsライクに生DOM API+αで構築されるのか、今はまだ定かではありません。
Remix v3は、WEB標準重視の方針のもと、開発されているので、Preactフォークの仮想DOMからの離脱もありえるかと思います。
8) Reactとの決別
Reactのユーザーベースは、今のところ、大きいので、そのユーザーベースからそっぽを向かれる可能性のある、React→Preactフォーク、Reactとは別の道を往く決断はRemix開発チームの自信の現れではないかと思います。
Remix3は、Reactによる制約から解き放たれ、設計/実装の自由度が格段に上がり、((Reactに「おまかせ」できていた部分も考えない/実装しないといけないので)設計/実装の難易度も上がった、とは思いますが...、)ReactベースのFWとは一味も二味も異なるFWになっています。
9) コンポーネント・ライブラリ
Reactベースではないため、Remix3では、shadcn/ui や Radix UI etcのReact用の有用なコンポーネント・ライブラリを利用することはできません。
Remix3(Preactフォーク)用のコンポーネント・ライブラリが開発中とのことです。
おそらく、shadcn/ui や Radix UI 相当のコンポーネント・ライブラリ。
推敲中…
Discussion