ここから先はミラーです。
Remix 3について書いてみます。
1) Remix.Handle.render、Remix.Handle.update
Remix 3では、コンポーネントのレンダリング・再レンダリングのマニュアル(手動)でのコントロールを可能にしています。
domパッケージ(モジュール)の機能として提供されています。
domパッケージ(@remix-run/dom)がRemix開発チームがPreactからフォークして？開発中のライブラリ(Preactフォーク？)であり、これらのメソッドは今後domパッケージに実装される(はずの)リアクティビティシステムから呼ばれることになるはずです。
リリース版Remix 3では、Remix.Handle.render、Remix.Handle.updateをユーザーが直接記述する機会は少なくなるはずです。
2) Remix.Handle.context
contextでの取り回しにProviderコンポーネントをかますことが必須のReactのcontextとは違い、RemixのcontextはVue.js 3のprovide/injectライクにset/getで取り回しができます。
contextでの取り回しは親→子コンポーネントへの一方通行です。
domパッケージ(モジュール)の機能として提供されています。
3) セットアップスコープ
Remix 3では、コンポーネントに記述されたステート(状態)の保持は、このセットアップスコープによって行われます。
Remix 3では、コンポーネントはクロージャとして扱われます。
Remix 3の中でコンポーネントは一度クロージャとして実行され、実行結果が(内部変数に)格納/保持され、(同一コンポーネントから)参照可能で、関数であるのに恰もオブジェクトであるかのように扱えるようになっています。
セットアップスコープでは、ステートはミュータブル(mutable: 可変)な値として扱われます。
Remix 3では、ReactやPreactベースのFW(フレームワーク)とは異なり、(セットアップスコープの段階では)ステートはミュータブル(mutable: 可変)な値として扱われます。
Preactフォーク？であるdomパッケージの完成形で、ステートがミュータブルな値として扱われるのか、イミュータブル(immutable: 不変)な値として扱われるのか、は不明です。
ステートの保持(自体)はセットアップスコープで行うため、domパッケージの完成形でステートがミュータブルな値として扱われる(＆リアクティビティが提供されない)場合、(ステート保持機能の実装は必要ないので)ステートを扱う機能(API)は存在しないままの可能性が高いです。
コンポーネント間でステートの共有はできないので、グローバルなステート管理には別途それ用のライブラリ(モジュール)が必要となります。
4) dom、events ...モジュール
Reactではreact-domパッケージがDOM API etcをカプセル化(隠蔽)していて、Reactの(抽象化された)インターフェイス(API)を介してしかDOM API etcにアクセスできないのに対して、Remix 3はDOM API/イベントetcが独自のインターフェイス(API)をもつモジュールとなっていて、それぞれにアクセス可能となっています。
Preactフォーク？であるdomパッケージは、Reactのように内部にイベントやレンダリングetc全てを内包するのではなく、DOMまわりetcは内包するものの、イベントまわりはevents、他もそれぞれ別モジュール？、として(別に)存在し、domパッケージ自体はそれらのモジュールを内部で利用する(Reactと比べて)コンパクトなライブラリになると考えられます。
Remix 3では、特定のライブラリに強く依存しない方針なので、Preactフォーク？であるdomパッケージに依存しすぎないしくみにしようとしているのかもしれません。
5) ステートの扱い＆リアクティビティ
Preactフォーク？であるdomパッケージの完成形がステート(状態)を扱う(リアクティビティ含む)APIを提供しないのか、Preactデフォルトの(Reactライクな)ステート用APIを採用するのか、Preact SignalsのようにSignalsを採用する(Preact Signalsもどき？を統合する？)のか、はたまた、第3のステート用APIを採用するのか、定かではありません。
何らかのリアクティビティが採用される場合、リアクティビティとステートを関連づける(ステートの変更を追跡する)ために、ステートを扱うAPIが必要になります。
Remix 3では、ステートの保持はセットアップスコープが担当するので、domパッケージでステートを扱うAPIが提供される場合、それはReactともPreactとも似て非なるモノです。
Remix3でステート用APIが提供されない場合、Alien Signals etcのリアクティビティを扱うライブラリと組み合わせて利用することで、リアクティビティを利用できます。
現状のプロトタイプ？を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(パス)で呼び出せるようになります。
リリース版Remix 3では、簡潔に書けるようになるはずです。
Remix 3でのルーティング定義の記述については、今のところ、demoアプリが一番の教材です。
ルーティング定義だけで、記事が書けます...
リリース版Remix 3では、URL/リソースベースルーティング に加え、ファイルベースルーティングも提供され、併用が可能になることに期待しています。
7) 仮想DOM
Preactフォーク？であるdomパッケージは、プロトタイプ・フェーズでは、Preactと同じく仮想DOMを採用しています。
ブラウザ(のレンダリングまわり(タイミングを含む))の実装の改善により仮想DOMがパフォーマンス上の優位性をなくし役割を終えようとしています。
(将来的に？)仮想DOMから離脱しSolid.jsライクに生DOM API+αで構築される可能性はゼロではないと思います。
Remix 3は、WEB標準重視の方針のもと、開発されているので、Preactフォーク？であるdomパッケージの仮想DOMからの離脱もありえるかと思います。
8) Reactとの決別
Reactのユーザーベースは、今のところ、大きいので、そのユーザーベースからそっぽを向かれる可能性のある、React→Preactフォーク？、Reactとは別の道を往く決断はRemix開発チームの自信の現れではないかと思います。
Remix開発チームの一番のスポンサーであるShopifyからの賛同は得られているはずです。
React ベースのReact Router7の開発・メンテナンスは継続されるので、Remix v2の既存ユーザーには、それほど大きな影響はないはず。
Remix 3は、Reactによる制約から解き放たれ、設計/実装の自由度が格段に上がり、((Reactに「おまかせ」できていた部分も考えない/実装しないといけないので)設計/実装の難易度も上がった、とは思いますが...、)ReactベースのFWとは一味も二味も異なるFWになっています。
WEB標準ではこう書けるのに、ReactではReactのルールに則ってReactの提供するインターフェイス(API)を使って書く(時には???な書き方をする)しかない。Reactでは、WEB標準の特定のAPIに対するアクセス手段がなく、(API)設計をそれに合わせるしかない。React(内部)の挙動を理解した上で、それに合わせた設計にするしかない。React(内部)の挙動を理解した上で実装しないと意図した挙動にできない。etcを、制約と書いています。
9) Remix 3の開発フェーズ
2025/07 開発スタート
2025/10 プロトタイプ・フェーズ
10) コンポーネント・ライブラリ
Remix 3は、Reactベースではないため、shadcn/ui や Radix UI etcのReact用の有用なコンポーネント・ライブラリを利用することはできません。
Remix 3(Preactフォーク？)用のコンポーネント・ライブラリが開発中とのことです。
おそらく、shadcn/ui や Radix UI 相当のコンポーネント・ライブラリです。
- ソースコード
現在、Remix3の@remix-run/*パッケージのソースコードはGithub上↑にはなく、それぞれのNPMパッケージのページのCode(リンク)から参照できます。
推敲中…