No.401
のと、あとデータ量に比例して重くなっていく問題をなんとかせんと
のと、あとデータ量に比例して重くなっていく問題をなんとかせんと
Vue vs React vs Angular vs Svelte Part.11
レス数: 476
概要: SSGもCORS問題が鬱陶しすぎる（ローカルで環境開発しにくいから開発コスト大） のと、あとデータ量に比例して重くなっていく問題をなんとかせんと
のと、あとデータ量に比例して重くなっていく問題をなんとかせんと
No.402
むしろView Transitions APIとか出てきてSPAは手軽に作れるようになってきてるから消えないよ
>>401
ReactだともうSSGは縮小方向だな
今はReactでマトモにSSGやろうとしたらAstroが一番の選択肢になりそう
No.403
フックの伝播複雑過ぎて、メンテナンスできない説。
No.404
No.405
No.406
No.407
自分で作ってもう触りたくない。
クリックのフックは子がハンドリングして親に返して、選択範囲の再描画は親が制御するみたいな。
これに余計な子は再描画しないようメモ化するとか入れると、頭こんがらがってくる。
どのフックで何のパラメータが変わってどれが再描画されるか解らなくなる。
設計書書かずに作ってるせいなんだが。
No.408
No.409
ttps://codepen.io/rkeqkdzm-the-reactor/pen/wBvWpyp
No.410
No.411
Solidはそこをしっかり解決してる
もう一つのゴミだったルーター系も
Solidインスパイアしてるならそっちも真似したらいいのに
Solidにストア系実装されたらまじでシェア流れかねんぞ
No.412
どこ情報？
No.413
何言ってるんだ？
Solid RouterはReact Routerにインスパイアされて作られたって公式のドキュメントに書いてあるのに
No.414
React Router Domが6からSolid Router（旧solid-app-router）の記法をまんま真似してるんだよ
パクったというより連携だけど
No.415
だけどreactで作ったchrome拡張の審査通った。
苦労して作ったから使ってみて欲しい。
適当なブログ開いて拡張のアイコンクリックすると画像一覧表示するから
欲しいの選択してダウンロードボタンでzipにできる。
スライダーで拡大縮小できるのがreactっぽい。
ttps://chromewebstore.google.com/detail/kakeaonncmnkigiijohfhlnondeaanii?utm_source=item-share-cp
No.416
No.417
No.418
No.419
No.420
簡単に情報抜かれる
No.421
No.422
No.423
いや
No.424
無駄に細分化すると面倒なことになる
必要になったら後からでもコンポーネント分けられるし
No.425
reRenderの単位かな
No.426
それまでは糞だけど。
No.427
自前のタイミングで再描画する楽しさよ
No.428
No.429
No.430
コンポーネントというより、質問のニュアンスだとフォーム部品ごとの出力オブジェクトか
制御フックのこと言ってるっぽいが
Reactはフォーム処理に関してSvelte、Vueにくらべたら糞性能というか、もともとが
深層ステート管理のためのライブラリだしな。複数のフォームを一発制御できる
useStateフックの書き方ググるかカスタムフックで作る
それかReact捨てて、簡単にリアルタイム制御できるVueかSvelteで作るかだな
どっちもストアライブラリ使わないとスパゲッティまっしぐらだがな
No.431
商用サイトじゃないけど、学研グループの勉強サイトはAstroで書かれてるね
https:
No.432
No.433
No.434
こんなのできるならよほど大規模なサービスでも無ければNext.jsは要らないのでは
No.435
Reactコンポーネントを将来、全く別のフレームワークのコンポーネント、例えば引数とレンダリング結果が同等の動きをする、コンパイルされたバイナリなんかに差し替えたりとか出来たら面白いな
No.436
近いうちにAIが直接SSGしたりWeb Assemblyを直接生成するようになるからフレームワークなんか消滅する
No.437
おまえの方が早く消滅しそう...
No.438
従来のRemixはReact Router v7になってRemix v3はpreactベースになるということか
No.439
オンライン麻雀ゲームを作成しようと構想(妄想)してるんだけど、
いまから新規に作るならフロント側にはReactかVue.jsか、あるいは他のライブラリのどれを使えばいい?
先駆者 (書籍も出してる) は
> jQueryでないと美しく実装できない
https:
って言ってるけど、Webゲームのクライアントは特殊ってこと?
No.440
そもそも状態管理をして宣言的にUIを構築するんだからむしろReactのほうがスッキリ書ける
jQueryおじさんという化石思考に惑わされてはいけない
No.441
いや、Reactでは描画のための状態はUIコンポーネント内部に保持することでコアロジックを汚染することなく打牌中のような中間状態を美しく描画することができる
No.442
アニメーションやユーザー操作に伴う一時的な状態、ここでは打牌中もコンポーネントの内部状態やコンテキストAPIとかで管理できる
isPlayingAnimationのようなブーリアン型の状態を用意し、アニメーション中はtrueに設定し、アニメーションが終了したらfalseに戻す
打牌中の牌の位置や動きに関する情報を状態として持ち、その状態に基づいてCSSアニメーションを適用する
No.443
Reactでも描画に関わる状態とアプリケーションのコアロジックに関わる状態は分離して管理するのが一般的
コアロジックの麻雀の牌姿やルール進行を司る部分は、Reactコンポーネントからは独立した純粋なJavaScriptクラスや関数として実装するのが普通
No.444
Reactの設計思想はコンポーネントが自身の描画とそれに関連するイベントハンドリングをカプセル化すること
「対戦相手の手牌にイベントハンドラは不要だし、牌譜再生にも打牌のためのイベントハンドラは不要」という点についてはReactのコンポーネント設計で柔軟に対応できるからまったく問題なし
isInteractive: booleanなどを渡すことでイベントハンドラの有無を制御できる
牌譜再生時にはイベントハンドラが不要なモードでコンポーネントを描画すればいいだけだし
No.445
> HTML に雛形として埋め込まれた「牌を表現するDOMノード」をコピーし差し込むことで実現しています。
Reactをまったく知らないからこんな恥ずかしことを堂々と言えるんだろう
こいつのもっとも無知なところだな
Reactは宣言型だからコピーするというコードを書くことすら不要なわけ
No.446
重くなることもなくていいんじゃね？って思うのは俺だけなのか
No.447
俺もこう思う
そもそも牌をhtml要素とCSSで描画すること自体が微妙だよね
そういう意味だとjQueryでもReactでもなくてCanvas系のフレームワーク使ったほうが良いんじゃないかな
No.448
No.449
Reactやビューで
あたかもHTMLの要素の様に操作できる（CSSプロパティ設定できる）
ライブラリってあるのかな。
No.450
