React でいい気がしてきた
- カテゴリ:
- JavaScript
- コメント数:
- Comments: 0
◆ React はコミュニティ大きい分 周辺ツールやライブラリ多め
◆ DOM 管理する分 既存の直接 DOM 操作する UI ライブラリと相性悪い
◆ lit-html や hyperhtml はその辺が不便
◆ これまで嫌だった部分はほぼなくなった
◆ DOM 管理する分 既存の直接 DOM 操作する UI ライブラリと相性悪い
◆ lit-html や hyperhtml はその辺が不便
◆ これまで嫌だった部分はほぼなくなった
React (Preact) + htm だと lit-html とほぼ同じ構文ですし 面倒なビルドも不要です
大規模ではないですが ありがちな Todo みたいな小さなものよりはちょっと複雑なものを作ってみてもこれと言って問題はなかったです
最近は React (Preact) でもいいかなーと思い始めてます
全部自分で作るなら問題にならないのですが 規模が大きくなると UI 系ライブラリを使いたいことが増えます
lit-html など DOM を管理するライブラリは外部で勝手に DOM を更新すると不整合がでます
そのため使えないものも多いです
React であればそれらのライブラリを React 用にラップしたり最初から React 用に作られた UI ライブラリが豊富です
UI 系に限らず テストや開発者ツールといった開発時のツールの充実度にも差があります
ただ これは lit-html なども同じで 慣れると別にいいやという気がしてきたので別にかまいません
色々作ってると DOM 操作を自分でやるのもめんどうになってきたところですし
困る部分はブラウザ側にバグがあったときなどです
Chrome は割と頻繁に何か問題がおきますし
どうにか回避策みつけて対処していますが それも直接 DOM 操作してるからやりやすい部分が多いです
内部で色々やられると対処しづらいこともありそうです
思ったとおり動かないけど原因が思いつかない場合 できる限りシンプルにしていくと 単純なネイティブ関数を実行しただけで再現するとか ブラウザ側の問題とわかることがあります
これにライブラリのレイヤが入るのでどっちが原因か調べづらいです
DOM の差分更新とか中身複雑ですし
あとはやはりパフォーマンスですが 無限スクロールみたいな HTMLElement の数がかなり多くなる作りにしなければ大丈夫だと思います
そういう状況で更新が重くなっても その数倍~数十倍くらいの時間が画面の再描画処理にかかるので DOM 処理の時間自体はそれに比べて些細なものです
そこを高速化しても最終的な DOM の状態が一緒なら再描画処理の時間は一緒です
11 秒かかるのが 10 秒になってもどっちでもいいですから
ただ htm を知る直前くらいでも lit-html と見比べて 「html`<h1>foo</h1>`」も「(<h1>foo</h1>)」もシンタックスハイライトされてると対して変わらないので見た目的にはどっちでもいいかなと思い始めてました
`` か () かくらいの違いです
使う場所も render メソッド内など限られていますし
JavaScript の構文に影響するのは気持ち悪いですが HTML タグのまとまりは関数呼び出しに変換されて式になるわけですし 既存のコードを変えないといけないようなことはないので変に気にするほどでもないかなと思ってます
あと JSX は XHTML で br や hr でも <br /> のように書かないといけないのは手間ですが これは htm と一緒です
これはこれで曖昧な HTML より良いかもと思ってます
自分で書く分にはともかく 読むとき変に省略されてるとわかりづらいのもありますから
それに HTML タグのエラーは lit-html や hyperhtml より親切になるのはメリットでもあります
ウェブページを作るだけでわざわざビルドツール入れたり環境準備して変更のたびにビルド必要ってすごく面倒なんですよね
これが framework 類を使わず DOM 操作や lit-html で済ませたい大きな理由でした
最近は npm から入れるライブラリも多くて ある程度の規模になると webpack や parcel は使わざるを得ないようになってきてます
しかし Rollup や Snowpack を使って npm パッケージ単位でバンドルすれば webpack よりはるかに楽です
これなら新しいパッケージを入れたり 依存関係に変更があったときだけバンドルすれば済みます
自分で書くコードは変換不要でそのまま ESModules としてロードします
これならビルドの苦労はほぼないのですが React で JSX を使うと別です
標準の JavaScript ではないので Babel による変換が必須です
それが 上の JSX のところに書いたように htm で不要になったのでビルド周りも楽になりました
他にも 不便な点はないわけではないですが React のみではなく lit-html などでも同じものです
コンポーネントに分けるならではの不便なところもありますが それは WebComponents でも言えるでしょうし むしろ WebComponents に比べると扱いやすい部分も多いです
React といいつつ Preact+htm ですが 今後使うことが増えそうな気がします
大規模ではないですが ありがちな Todo みたいな小さなものよりはちょっと複雑なものを作ってみてもこれと言って問題はなかったです
最近は React (Preact) でもいいかなーと思い始めてます
周辺ツール・ライブラリ
lit-html や hyperhtml は小さくて扱いやすいのですが ユーザ数やコミュニティ的には React には及びません全部自分で作るなら問題にならないのですが 規模が大きくなると UI 系ライブラリを使いたいことが増えます
lit-html など DOM を管理するライブラリは外部で勝手に DOM を更新すると不整合がでます
そのため使えないものも多いです
React であればそれらのライブラリを React 用にラップしたり最初から React 用に作られた UI ライブラリが豊富です
UI 系に限らず テストや開発者ツールといった開発時のツールの充実度にも差があります
避けてた理由
これまで React をあんまり使おうと思わなかった嫌な部分は主にこれです- DOM操作しない
- JSX
- ビルド
DOM
DOM を操作できない分 自由度は減りますし イベントに応じて必要最低限のところだけ変えればいいのに 今の状態から DOM の差分探して更新は無駄が多いですただ これは lit-html なども同じで 慣れると別にいいやという気がしてきたので別にかまいません
色々作ってると DOM 操作を自分でやるのもめんどうになってきたところですし
困る部分はブラウザ側にバグがあったときなどです
Chrome は割と頻繁に何か問題がおきますし
どうにか回避策みつけて対処していますが それも直接 DOM 操作してるからやりやすい部分が多いです
内部で色々やられると対処しづらいこともありそうです
思ったとおり動かないけど原因が思いつかない場合 できる限りシンプルにしていくと 単純なネイティブ関数を実行しただけで再現するとか ブラウザ側の問題とわかることがあります
これにライブラリのレイヤが入るのでどっちが原因か調べづらいです
DOM の差分更新とか中身複雑ですし
あとはやはりパフォーマンスですが 無限スクロールみたいな HTMLElement の数がかなり多くなる作りにしなければ大丈夫だと思います
そういう状況で更新が重くなっても その数倍~数十倍くらいの時間が画面の再描画処理にかかるので DOM 処理の時間自体はそれに比べて些細なものです
そこを高速化しても最終的な DOM の状態が一緒なら再描画処理の時間は一緒です
11 秒かかるのが 10 秒になってもどっちでもいいですから
JSX
これは htm のおかげで不要になりましたただ htm を知る直前くらいでも lit-html と見比べて 「html`<h1>foo</h1>`」も「(<h1>foo</h1>)」もシンタックスハイライトされてると対して変わらないので見た目的にはどっちでもいいかなと思い始めてました
`` か () かくらいの違いです
使う場所も render メソッド内など限られていますし
JavaScript の構文に影響するのは気持ち悪いですが HTML タグのまとまりは関数呼び出しに変換されて式になるわけですし 既存のコードを変えないといけないようなことはないので変に気にするほどでもないかなと思ってます
あと JSX は XHTML で br や hr でも <br /> のように書かないといけないのは手間ですが これは htm と一緒です
これはこれで曖昧な HTML より良いかもと思ってます
自分で書く分にはともかく 読むとき変に省略されてるとわかりづらいのもありますから
それに HTML タグのエラーは lit-html や hyperhtml より親切になるのはメリットでもあります
ビルド
これも htm のおかげで不要になりましたウェブページを作るだけでわざわざビルドツール入れたり環境準備して変更のたびにビルド必要ってすごく面倒なんですよね
これが framework 類を使わず DOM 操作や lit-html で済ませたい大きな理由でした
最近は npm から入れるライブラリも多くて ある程度の規模になると webpack や parcel は使わざるを得ないようになってきてます
しかし Rollup や Snowpack を使って npm パッケージ単位でバンドルすれば webpack よりはるかに楽です
これなら新しいパッケージを入れたり 依存関係に変更があったときだけバンドルすれば済みます
自分で書くコードは変換不要でそのまま ESModules としてロードします
これならビルドの苦労はほぼないのですが React で JSX を使うと別です
標準の JavaScript ではないので Babel による変換が必須です
それが 上の JSX のところに書いたように htm で不要になったのでビルド周りも楽になりました
残りは React 以外でも
という感じでこれまで避けてきた理由はほとんどなくなりました他にも 不便な点はないわけではないですが React のみではなく lit-html などでも同じものです
コンポーネントに分けるならではの不便なところもありますが それは WebComponents でも言えるでしょうし むしろ WebComponents に比べると扱いやすい部分も多いです
React といいつつ Preact+htm ですが 今後使うことが増えそうな気がします