Vue vs React vs Angular vs Svelte Part.11 (452ﾚｽ)
上下前次1-新
1: (ﾜｯﾁｮｲ 434e-OHyh) 2022/08/20(土)13:17 ID:OuD+ytSs0(1) AAS
!extend:on:vvvvv:1000:512
Vue
外部ﾘﾝｸ:jp.vuejs.org
React
外部ﾘﾝｸ:reactjs.org
Angular
外部ﾘﾝｸ:angular.io
Svelte
外部ﾘﾝｸ:svelte.dev
solid.js
省11
326(1): (ﾜｯﾁｮｲ 63f0-bFHd) 2024/09/29(日)17:47 ID:xSeXse3x0(6/9) AAS
>>324
違う
単にSQL生成を目的とするだけのモジュール
railsにおけるArelとか
以下のように複雑なSQLも構築可能
Task.where(
Arel::Nodes::NamedFunction.new(
'TO_CHAR',
[
Task.arel_table[:created_at],
省7
327: (ﾜｯﾁｮｲ b3ba-eLKd) 2024/09/29(日)17:54 ID:8BzfSqEJ0(2/3) AAS
>>317
いちばん有名な企業が楽天グループ、そこは公認パートナー企業にもなってる
>>325
ORMは便利だけどそっちしか知らない人が多いというか、各種フレームワークからデバッグ用にSQL吐き出せること知らない人も多い。だから結合とか副問い合わせで躓いてるのをよく質問サイトで見かけたな
328(2): (ﾜｯﾁｮｲ ff3c-gB8o) 2024/09/29(日)18:05 ID:/6K/Gjr+0(1/3) AAS
おぞましいことに、SELECT * FROM xxx WHERE yyy = zzzみたいな糞クエリのゴリ押しだけで全部解決しようとする新人がたまにいるのよ
明らかにJOINやサブクエリやウィンドウを使えば効率的に一度のクエリで解決する要件も、何回も何十回もクエリ発行して取りに行く
負荷試験が壊滅的だったプロジェクトに火消しを頼まれて助っ人で行ってみたらそんなザマで頭抱えたことがある
結局ほとんど俺が全部書き直した
329: (ﾜｯﾁｮｲ ff3c-gB8o) 2024/09/29(日)18:20 ID:/6K/Gjr+0(2/3) AAS
あんなDBの使い方しかしない（できない）からORMの弊害に気付かないんだと思うわ
型安全と言っても、それテーブルの全カラムを無加工で取得したい場合ぐらいしか有効に働かないだろうに
330: (ﾜｯﾁｮｲ e36b-v4Ln) 2024/09/29(日)18:29 ID:4S/kVkYa0(4/6) AAS
>>326
ストレートーにSQL書けよと言いたくなるな
障害時に綺麗なSQLはけてないと復旧とか損害保証とかできるの？
331(2): (ﾜｯﾁｮｲ e36b-v4Ln) 2024/09/29(日)18:36 ID:4S/kVkYa0(5/6) AAS
>>328
昔DBAという役職があって
その人に使用するSQL全部チェック対象にされ...
332(1): (ﾜｯﾁｮｲ ffad-JJSI) 2024/09/29(日)18:38 ID:1Tb71lk/0(1) AAS
ストレートにSQL書くと、パラメーターとの文字列連結がカオスになるよ
333: (ﾜｯﾁｮｲ e36b-v4Ln) 2024/09/29(日)18:41 ID:4S/kVkYa0(6/6) AAS
サブクエリに、with、一時table使ってSQL書いてるけどそんな事一度もなかったな
334: (ﾜｯﾁｮｲ 63f0-bFHd) 2024/09/29(日)18:43 ID:xSeXse3x0(7/9) AAS
今回の調査で色々と調べたけど
javaのJOOQってORMやべーな
とんでないぞこのライブラリ
以下のように型がコロコロ変わる場合でもちゃんと書ける
Fieldクラスを抽象化することで静的な型チェックが可能になっている
この発想はなかった
DSLContext create = DSL.using(configuration);
Field<String> caseField = DSL.case_()
.when(field("age", Integer.class).gt(18), "adult")
.when(field("age", Integer.class).lt(18), "minor")
省2
335: (ﾜｯﾁｮｲ 63f0-bFHd) 2024/09/29(日)18:45 ID:xSeXse3x0(8/9) AAS
caseってデータ分析ではめちゃくちゃ使うのだけど
これがこんな感じで書ける
素晴らしい
336: (ﾜｯﾁｮｲ 63f0-bFHd) 2024/09/29(日)18:47 ID:xSeXse3x0(9/9) AAS
>>331
昔は社内にオラクルデータベースの番人みたいなおじさんがいたなあ
337: (ﾜｯﾁｮｲ b3ba-eLKd) 2024/09/29(日)19:00 ID:8BzfSqEJ0(3/3) AAS
>>328
select * from tableA join tableBとして、吐き出した全データを配列に格納、展開してたトンデモプログラムをデバッグしたことあるよ…。アスタリスクは百歩譲ってもせめて部分結合してくれ
データ数千件しかないのにフォーム処理クッソ重いと思ったらこれだよ
338: (ﾜｯﾁｮｲ 6f90-v4Ln) 2024/09/29(日)19:25 ID:Ck7eDstu0(1) AAS
>>332
一回のトランザクション処理につき一回だけSQL実行可とルールすればよい
おのづとサブクエリ、with、一時tableを使う事になって、SQL投げて結果でSQL投げみたいな処理を繰り返すヘボ実装が一掃される
339: (ﾜｯﾁｮｲ ff3c-gB8o) 2024/09/29(日)19:26 ID:/6K/Gjr+0(3/3) AAS
>>331
たいがいそこが開発進行のボトルネックになってたけど当時は必要悪だったと思うよ
あの頃のオンプレの商用環境（しかも大抵カツカツの構成）で、クソゴミクエリぶん回そうものなら即死してサービスダウンに陥ってたもんよ
今のクラウドのマネージドDBだったらただ遅いor費用が嵩むだけで落ちるとこまで行くことはそうそうないけど、昔は死活問題だった
340: (ｱｳｱｳｴｰ Sadf-D2eP) 2024/09/30(月)14:16 ID:5Q41gUpla(1) AAS
一つの処理を一つのSQLクエリならアトミックになって問題無いけど
一つの処理を複数のSQLクエリで時間差が出来るから他所からデータ割り込まれたら困るケースがあるだろ
そこまで考慮してないアホばっか
341(1): (ﾜｯﾁｮｲ 7f85-D2eP) 2024/09/30(月)16:35 ID:eyZN3jLh0(1) AAS
一番早いのは個々のSQL連結したをストアドなんだよなー
JOINもINNNERとRIGHTは遅いからLEFTのみ
342: (ﾜｯﾁｮｲ 3fd9-GmTs) 2024/09/30(月)16:59 ID:90xjyaJO0(1) AAS
>>341
inner使ってたけどleftのが速いんだ？
343: (ﾜｯﾁｮｲ 7fd8-gB8o) 2024/09/30(月)22:19 ID:x8UwNGco0(1) AAS
そもそも得られる結合結果が違うし、INNERのほうが効率的なケースもLEFTのほうが効率的なケースも存在するから思考停止せずにしっかり実行計画確認しろ
「何にでも～～を使う！」ってのはバカの一つ覚えってんだ
344(1): (ﾜｯﾁｮｲ cfcf-KiE/) 2024/09/30(月)22:31 ID:2/RvbFVp0(1) AAS
left と right で速度が違うとか言ってる奴の話を真に受けんな
345(1): (ﾜｯﾁｮｲ e36e-v4Ln) 2024/09/30(月)23:41 ID:6IhSUC9Z0(1) AAS
>>344
結構あるで
346: (ｻｻｸｯﾃﾛ Sp47-F/l5) 2024/10/01(火)10:17 ID:tNPrHSB3p(1) AAS
リスト構造なら違いは無いよな？
347: (ﾜｯﾁｮｲ 3f4d-GmTs) 2024/10/01(火)16:04 ID:20pFp1ah0(1/3) AAS
本読んでたらNextすげーいいじゃんと思ってきた、なんか学習コストは高そうな気がするけど
remixは調べてない
348: (ﾜｯﾁｮｲ 63f0-bFHd) 2024/10/01(火)16:46 ID:Ig6Tf0ue0(1/3) AAS
最近はremixの方が優勢になってきてる
ChatGPTもnext.jsだったのにremixに移行した
349: (ﾜｯﾁｮｲ 63f0-bFHd) 2024/10/01(火)16:47 ID:Ig6Tf0ue0(2/3) AAS
ただしremixはフルスクラッチで作り直すから
大幅に変わりそう
だから今手を出すべきかは微妙
350: (ﾜｯﾁｮｲ 3f4d-GmTs) 2024/10/01(火)16:48 ID:20pFp1ah0(2/3) AAS
どっちにしろ新規プロジェクトだからNextかなあ
351: (ﾜｯﾁｮｲ 3f4d-GmTs) 2024/10/01(火)16:49 ID:20pFp1ah0(3/3) AAS
じゃないRemix
352: (ﾜｯﾁｮｲ 8f1f-bFHd) 2024/10/01(火)18:54 ID:gaoRlfpT0(1) AAS
まあフロントエンドなんて作り直すのは基本だし
まともなCTOがいたら予算も出るからその時の流行でよろしい
画面の動きを全部サーバーサイドの結果で判断できるように作っておけば問題なし
353: (ｽｯｯﾌﾟ Sd1f-9JCP) 2024/10/01(火)22:29 ID:V2w3Ucz+d(1) AAS
プロダクトの性質次第だろう
SaaSだとページ数多いしビジネス要件実装のウェイトが大きいから作り直しは難しい
354(1): (ﾜｯﾁｮｲ cfcf-KiE/) 2024/10/01(火)22:30 ID:7hV/Zxp/0(1) AAS
>>345
ねーわ。どっちも outer join で駆動表が右か左か違うだけ。
クエリを書き換えて実行計画が変わったのを勘違いしただけだろ。
355(1): (ﾜｯﾁｮｲ 8f88-v4Ln) 2024/10/01(火)22:41 ID:PxjtxeQz0(1) AAS
>>354
あるで調べてみ
356: (ﾜｯﾁｮｲ ff6c-gB8o) 2024/10/01(火)22:45 ID:GFljMLhp0(1) AAS
leftと等価なrightへの書き換え、あるいはその逆の書き方を知らないだけでは？🤔
357: (ﾜｯﾁｮｲ 63f0-bFHd) 2024/10/01(火)23:53 ID:Ig6Tf0ue0(3/3) AAS
right joinを使う必要があるとは思えんな
358(1): (JP 0Hdf-GCHr) 2024/10/02(水)07:12 ID:H5d/PPBcH(1) AAS
345は20年前のOracle8iみたいなルールベースの知識からアップデートできていないだけな気がする
359: (ｽﾌﾟｯｯ Sd1f-PqsP) 2024/10/02(水)08:15 ID:L5vBX47Zd(1) AAS
>>355
あるっつうならその実例出して
360: (ﾜｯﾁｮｲ e3a8-v4Ln) 2024/10/02(水)12:21 ID:XNBCv0lf0(1) AAS
>>358
そーーかも
361: (ﾜｯﾁｮｲ 6fcd-fhRs) 2024/10/02(水)12:40 ID:VhOKxDCS0(1) AAS
なんとなくいつもleftだわ
362: (ﾄﾞｺｸﾞﾛ MMff-Z4n8) 2024/10/02(水)15:21 ID:ntIVC1snM(1) AAS
Nextはビルドツールが自前なのがな
RemixもsveltekitもNuxtもVite使ってるからそこでエコシステムの差が出てきそう
それが進んだらNextも厳しくなってくる
363: (ﾜｯﾁｮｲ 63f0-bFHd) 2024/10/02(水)16:20 ID:TLprtWVf0(1) AAS
JSはいつまでエコシステムとかやるんすかね
いい加減デファクトをみんなで作ろうよってならないのかね
主に政治的思惑で一つにしたくないのだろうけど
364: (ﾜｯﾁｮｲ 83ea-gB8o) 2024/10/02(水)17:16 ID:BpVEd4dp0(1) AAS
right joinを使うと右から左へ、下から上へ読むようなクエリになるからな
読みづらいからrightは基本使わない
「遅いからrightは使わない」とか言ってる人は意味不明だけど
365: (ﾜｯﾁｮｲ b371-bFHd) 2024/10/02(水)17:22 ID:xvxi+lxb0(1) AAS
昔のDBでそういうのがあったんじゃないの？
知らんけど
366: (ﾜｯﾁｮｲ c3db-jIqN) 2024/10/03(木)00:02 ID:fliyUvHO0(1) AAS
まあ特に理由がなければleftだよなあ
367: (ﾜｯﾁｮｲ 23ee-9JCP) 2024/10/05(土)12:16 ID:RBSjgErc0(1) AAS
HR系のシステムにおける従業員(主)と部署(従)のように、あるビジネスドメインにおいて着目する主体ってのはだいたい決まっているものだ
なので、SQLを書くときもそのメンタルモデルに倣って主側に置くものをある程度固定したほうが読みやすいという考え方もある
ある条件を満たす従業員と所属部署の一覧を表示する際に、従業員不在の部署も表示したいという要件があったとして、
そのようなちょっとしたビュー要件によって主従関係が逆転してしまうのは好ましくない、ということだ
俺はそれでもLEFT統一の方が読みやすいと思う派だが、考え方としては理解できるものだろう
368: (ﾜｯﾁｮｲ eb23-vAd8) 2024/10/19(土)07:55 ID:kXgKzXcr0(1) AAS
svelte5のmilestoneが98%まで回復
369: (ﾜｯﾁｮｲ 1923-pdRO) 2024/10/20(日)20:29 ID:XEBgqfIg0(1) AAS
release svelte@5.0.0
370(1): (ﾜｯﾁｮｲ 1901-h/XG) 2024/10/28(月)10:56 ID:MeMed5MX0(1) AAS
svelteで作っていたサイトはもうastroにしたんだよなあ
svelteの強味がよくわからなかった
371: (JP 0H63-gQDg) 2024/10/29(火)22:21 ID:yFBNIKKHH(1/2) AAS
BEｱｲｺﾝ:nida.gif
EchoAPIは、テストが私のReactアプリに動力を提供するAPIを容易にし、開発を強化するための迅速な応答を提供。試してみてね
372: (JP 0H63-gQDg) 2024/10/29(火)22:22 ID:yFBNIKKHH(2/2) AAS
BEｱｲｺﾝ:nida.gif
EchoAPIの直感的なインタフェースは、ReactアプリケーションでAPI応答を迅速に検証し、デバッグを容易にするのに役立つ。おすすめ！
373(2): (ﾜｯﾁｮｲ f701-yqoI) 2024/12/27(金)03:32 ID:hxF8JUMM0(1) AAS
Angularが久しぶりに盛り返してる
今年のアプデでかなり改善されたからだろうか
あと特筆すべきことはAstroの伸びかな
外部ﾘﾝｸ:2024.stateofjs.com
374: (ｽｯﾌﾟﾌﾟ Sd9b-JlZ7) 2024/12/27(金)20:34 ID:YxIFlKOGd(1) AAS
本当だVue抜いてるじゃん
Astroは絵に描いた餅感のイメージ強いんだけど、
この間bolt適当に弄ってたら何故かASTROでコード吐いてきたので
AIの力も借りて遊びでなんか作ってみようかなぁ
375: (ﾜｯﾁｮｲ 61f0-nFNZ) 2024/12/28(土)02:05 ID:PwEyBlKD0(1) AAS
いやもうReactでいいよ…
376: (ﾜｯﾁｮｲ f701-yqoI) 2024/12/28(土)06:54 ID:e4Tyi2oC0(1) AAS
jsx使ったことある人ならAstroは簡単に習得できると思う
377: (ﾜｯﾁｮｲ 0fba-mSSC) 02/08(土)10:31 ID:hJvS4i6R0(1/2) AAS
>>373
Angular17以降爆速になったからな、Vite＋esbuildというチートで19は起動が6秒ぐらい
それでいてフルスタックのまま。スタンドアロン標準実装、Signal、ビルトインコントロールフロー
ようやく他と戦える体勢整ってきた
>>370
SvelteはAppleが協賛に入って脱TS目指して、アプリ特化になりつつある
Runeもまだ、既存技術をわかりやすくマーキングしただけだし
378: (ﾜｯﾁｮｲ 0fba-mSSC) 02/08(土)11:14 ID:hJvS4i6R0(2/2) AAS
>>373
Viteの伸びもえぐいな、とうとうWebpack超えてしまったか
Reactも19になってようやく不満要素だった、テンプレート周りの改善とフォームのリアクティブ制御を実現してきた
ただReact普及に貢献してきたNextだけが、案の定Viteから爪弾き状態になってるのが気がかり
Remix、Astroはしっかり公式連携になってるのに
379: (ﾜｯﾁｮｲ ffba-kH5e) 02/09(日)16:00 ID:G+MTHt9S0(1) AAS
あとAngularはCSR、SSG、SSRをミックスした使い方ができる。これはフルスタックならではの強みであり芸当でもある
380(2): (ﾜｯﾁｮｲ 0aad-jTq6) 02/09(日)18:38 ID:wFwap3vs0(1) AAS
Angularってどう学べばいいの？
書籍は古いバージョンしか出てないし
公式サイト（日本）のはじめてのAngularだかも
今のバージョンでは動かなかったりして当てにならなかったわ
381: (ﾜｯﾁｮｲ 1ae4-fV+3) 02/09(日)23:00 ID:XCB8NOLW0(1) AAS
>>380
やっぱり本家のチュートリアルかねえ英語だけど
日本語の書籍は古すぎてオススメできない
382: (ﾜｯﾁｮｲ 3f44-imkm) 02/11(火)10:22 ID:jvkFh9pY0(1) AAS
>>380
ZennかQiitaあたりの使える記事を探すのが手っ取り早いかな
英語読めたらdev communityにも役立つ記事がいっぱいあるけど
Angularも14以降とそれ以前でReactの16.8以降と以前ぐらい別物の記述になってるから注意
あとAngular19からはstandalone標準だから、過去の動かしたい場合はstandalone: falseにしないと動かない
383: (ﾜｯﾁｮｲ eb01-LhIj) 02/11(火)17:22 ID:nxcjaTzm0(1) AAS
AngularはFCP遅いのがな
一度読み込んだら速いけど
384: (ﾜｯﾁｮｲ 3f44-imkm) 02/15(土)10:10 ID:HGo6DyGJ0(1) AAS
最近の業務待機時間多いから、その合間にここ数年の流行りに取り組んでいるんだけど
solidJSがかなり書きやすくていい。Vueのようなライフサイクルフックもあるし、JSXのループ周りに対しても面倒なmap地獄に遭わなくて済む。Reactかじってたら多分すぐ覚える
システム複雑じゃなくていいけど、JSXでさっと書きたいって人にはおすすめ
RemixとAstroもいい感じだ
RemixはNextほど複雑さがないし
AstroはJSX、Vue、Svelte、Solidどの書き方も通るのが便利そう
385: (ﾜｯﾁｮｲ 6a57-l5Ii) 02/15(土)14:53 ID:yHUAMZfW0(1) AAS
でも案件ないからね
386(2): (ﾜｯﾁｮｲ 1501-oe3m) 02/16(日)01:34 ID:T2962Blt0(1) AAS
ネットうろうろしてるとNextどころか
まだまだVue、Nuxt多いなぁ
Astroとか日本の商用サイトで採用してるとこあるの？
387: sage (ﾜｯﾁｮｲ 6d44-ot0k) 02/16(日)08:57 ID:l718zIOz0(1) AAS
どこで何が役立つかわからん業界だし（今年はまさかのPerl大活躍）
>>386
Astro採用企業の有名どころはAmazon、ネトフリ、クックパッド（ここはかなり日和るが）とか
Microsoftもスポンサーになってるのが大きいかな、あとVite公認
388: (ﾜｯﾁｮｲ 4501-990B) 02/16(日)09:40 ID:TK5HkbV90(1) AAS
GoogleとかトリバゴもAstro使ってるはず
国内企業は知らんけど
389(1): (ｱｳｱｳｳｰ Sa49-CJ2S) 02/19(水)06:48 ID:Z9GTaoqfa(1) AAS
Remix良いとは思うんだけど
こういうフレームワークを更にラップしたようなのって流行過ぎた頃に困る予感しかしないんだよな
バックエンド含んでるから古くてもまぁ動けばええじゃろでサボることもできんし
390: (ﾜｯﾁｮｲ 4501-990B) 02/19(水)07:02 ID:tFpAjYQB0(1) AAS
>>389
どのフレームワーク使ってもその問題は付きまとうから気にしても意味ないような
391: (ﾜｯﾁｮｲ 43d9-XFKP) 02/19(水)07:36 ID:cyNyT1yf0(1/2) AAS
create-react-appが非推奨になったとかなんとか
392: (ｽﾌﾟｰﾌﾟ Sd43-oe3m) 02/19(水)13:07 ID:3+8LLoUvd(1) AAS
フルスタックものはだいたいそのリスクあるでしょ
堅牢なシステムを長期的に運用したいとかなんとかなら
結局愚直にバックエンドapi実装
393: (ﾜｯﾁｮｲ 1b7b-iI+e) 02/19(水)14:31 ID:mGrw3aeq0(1) AAS
大規模ならCOBOLかJAVAだろうね
394: (ﾜｯﾁｮｲ 43d9-XFKP) 02/19(水)14:34 ID:cyNyT1yf0(2/2) AAS
フルスタックのリスク回避でapiは別に設けるのもアリだよねって思ってもいる
Remixイジり始めたばかりだけど
395: (ﾜｯﾁｮｲ edba-vA3c) 02/20(木)20:55 ID:NisJn+800(1) AAS
海外ではQwikも人気出てきてるみたいだし本当に群雄割拠だ
自分は今、Svelteのrune触りまくってるけど、一層proxy制御ガチガチになってて
堅牢性と拡張性は大幅に改善されてたけど、あれじゃもう、Vueと並び初級者向けとは言えんぞ
396(2): (ﾜｯﾁｮｲ 35cf-JytB) 02/21(金)02:50 ID:y9XPTlRE0(1/2) AAS
Reactみたいに汎用的なフレームワークは消えると思ってる
やっぱり個別にコンポーネントをコンパイルした方が効率いいのは間違いないのだし
サーバーサイドありきにするならこの考えが自然なのよね
397(1): (ﾜｯﾁｮｲ 4501-990B) 02/21(金)05:02 ID:9D9p9cHN0(1) AAS
>>396
litのこと言ってるのか？
398: (ﾜｯﾁｮｲ 35cf-JytB) 02/21(金)18:42 ID:y9XPTlRE0(2/2) AAS
>>397
いや基本的にはサーバー側でオンザフライにコンパイルされることが基本となると思う
svelteやqwik、solidを融合したような形になると思う
399: (ﾜｯﾁｮｲ edba-ot0k) 02/21(金)20:23 ID:xhvBpgKe0(1) AAS
>>396
ReactとVueはあくまでライブラリだからな。だからガワ（フロントエンドツール）として売り出す手段にも出てるわけで。それだけにReactもそろそろ使いやすさ重視しないと離れていくだろうな
特に、今後のエコシステム次第ではSolidに乗り換えられる可能性は大いにある
VueはdefineModelがチート性能すぎてある意味今後が怖い
400(1): (ﾜｯﾁｮｲ fdf0-tmLj) 02/22(土)13:52 ID:IP1R//230(1) AAS
spaとか糞なUIはそろそろ消えると予想。
画面リロードに対応できない仕組みでUI構築すべきではないと気付き始めるだろ。
401(1): (ﾜｯﾁｮｲ b1ba-8jxH) 02/23(日)10:18 ID:EtTS1kqD0(1/2) AAS
SSGもCORS問題が鬱陶しすぎる（ローカルで環境開発しにくいから開発コスト大）
のと、あとデータ量に比例して重くなっていく問題をなんとかせんと
402: (ﾜｯﾁｮｲ 9501-7f0F) 02/23(日)11:27 ID:SIbO7j//0(1) AAS
>>400
むしろView Transitions APIとか出てきてSPAは手軽に作れるようになってきてるから消えないよ
>>401
ReactだともうSSGは縮小方向だな
今はReactでマトモにSSGやろうとしたらAstroが一番の選択肢になりそう
403: (ﾜｯﾁｮｲ 31a5-c6km) 02/23(日)16:53 ID:hoXt0H0e0(1) AAS
react難し過ぎるだろ。
フックの伝播複雑過ぎて、メンテナンスできない説。
404: (ﾜｯﾁｮｲ 31f6-dlJU) 02/23(日)20:10 ID:NHXxiQzh0(1) AAS
まったく問題ないが
405: (ﾜｯﾁｮｲ b1ba-8jxH) 02/23(日)20:19 ID:EtTS1kqD0(2/2) AAS
コールバック関数、分割代入、proxy この３つを把握すればJSフレームワークはどれも同じ
406: (ﾜｯﾁｮｲ 5abb-FQm1) 02/23(日)22:02 ID:VD63caIp0(1) AAS
笑
407(1): (ﾜｯﾁｮｲ 752d-c6km) 02/23(日)23:52 ID:SCNJLFbC0(1) AAS
reactでShift選択するui作ったけど
自分で作ってもう触りたくない。
クリックのフックは子がハンドリングして親に返して、選択範囲の再描画は親が制御するみたいな。
これに余計な子は再描画しないようメモ化するとか入れると、頭こんがらがってくる。
どのフックで何のパラメータが変わってどれが再描画されるか解らなくなる。
設計書書かずに作ってるせいなんだが。
408: (ﾜｯﾁｮｲ 3d95-Ek8k) 02/24(月)01:31 ID:BUsCxVnh0(1) AAS
逆に生で作ることを考えたらまだマシとなる
409: (ﾜｯﾁｮｲ 3174-W5vA) 02/24(月)02:07 ID:9ouheju+0(1) AAS
Shift選択のUIってこんな感じの挙動？
外部ﾘﾝｸ:codepen.io
410(1): (ﾜｯﾁｮｲ 9501-phV/) 02/24(月)05:09 ID:Mu/PIHkN0(1/2) AAS
ReactのMemoはマジでゴミだけどReact Compilerでやっと解決するらしいから
411(2): (ﾜｯﾁｮｲ b1ba-8jxH) 02/24(月)08:41 ID:ApFSqceQ0(1/2) AAS
Reactでゴミなのはコントロールフロー系
Solidはそこをしっかり解決してる
もう一つのゴミだったルーター系も
Solidインスパイアしてるならそっちも真似したらいいのに
Solidにストア系実装されたらまじでシェア流れかねんぞ
412: (ﾜｯﾁｮｲ d505-FQm1) 02/24(月)09:31 ID:ESLDFy060(1) AAS
>>410
どこ情報？
413: (ﾜｯﾁｮｲ 9501-phV/) 02/24(月)10:02 ID:Mu/PIHkN0(2/2) AAS
>>411
何言ってるんだ？
Solid RouterはReact Routerにインスパイアされて作られたって公式のドキュメントに書いてあるのに
414: (ﾜｯﾁｮｲ b1ba-8jxH) 02/24(月)10:30 ID:ApFSqceQ0(2/2) AAS
>>411
React Router Domが6からSolid Router（旧solid-app-router）の記法をまんま真似してるんだよ
パクったというより連携だけど
415: (ﾜｯﾁｮｲ 752d-gfH/) 02/27(木)01:30 ID:5g/Kzzkv0(1/3) AAS
>>407だけどreactで作ったchrome拡張の審査通った。
苦労して作ったから使ってみて欲しい。
適当なブログ開いて拡張のアイコンクリックすると画像一覧表示するから
欲しいの選択してダウンロードボタンでzipにできる。
スライダーで拡大縮小できるのがreactっぽい。
外部ﾘﾝｸ:chromewebstore.google.com
416: (ｽｯﾌﾟﾌﾟ Sdfa-/AOM) 02/27(木)14:33 ID:0d0Ldapzd(1) AAS
気が向いたらソースコード公開して
417: (ﾜｯﾁｮｲ 3d63-Ek8k) 02/27(木)15:23 ID:C53SLMw00(1) AAS
なんでこんなところで宣伝してるんだよ…
418: (ﾜｯﾁｮｲ 752d-gfH/) 02/27(木)17:26 ID:5g/Kzzkv0(2/3) AAS
reactらしいアプリ作ったから見て欲しかった。
419: (ﾜｯﾁｮｲ 752d-gfH/) 02/27(木)17:40 ID:5g/Kzzkv0(3/3) AAS
作ったのほとんどAIなんだけどね・・・
420: (ﾜｯﾁｮｲ 8dbf-dlJU) 02/28(金)01:45 ID:GlQ+7ZAn0(1) AAS
誰が作ったのかもわからん怪しいextensionなんかインストールしてはいかんよ
簡単に情報抜かれる
421: (ﾜｯﾁｮｲ 3d79-Ek8k) 02/28(金)11:51 ID:xWWtZGU60(1) AAS
公式でもザルだから入れない
422(3): (ﾜｯﾁｮｲ 7387-kHpM) 03/02(日)15:42 ID:AnJsL6nW0(1) AAS
みんなReactでフォーム作るときってinputタグ単位でコンポーネント作るの？
423: (ﾜｯﾁｮｲ 6951-5VVp) 03/02(日)16:48 ID:YYvymA+Y0(1) AAS
>>422
いや
424: (ﾜｯﾁｮｲ 9901-fJMW) 03/02(日)17:33 ID:Zv8rdJ2Y0(1) AAS
コンポーネントって再利用しやすいように作るのであって
無駄に細分化すると面倒なことになる
必要になったら後からでもコンポーネント分けられるし
425: (ﾜｯﾁｮｲ b16e-e/WV) 03/03(月)02:31 ID:VRiiOt5H0(1) AAS
>>422
reRenderの単位かな
426: (ﾜｯﾁｮｲ 592d-bSvP) 03/03(月)18:58 ID:Smhsplev0(1) AAS
描画のタイミング自由に制御できるようになると、react楽しいねぇ。
それまでは糞だけど。
427: (ﾜｯﾁｮｲ 1962-e/WV) 03/03(月)19:53 ID:s56BTABZ0(1) AAS
Reactのranderを封じて、
自前のタイミングで再描画する楽しさよ
428: (ﾜｯﾁｮｲ 9901-fJMW) 03/03(月)23:50 ID:uSk7XRpe0(1) AAS
Reactはmillion.js使えばsvelteやsolidよりレンダリングのパフォーマンスが良くなるよ
429: (ﾜｯﾁｮｲ 698f-5VVp) 03/04(火)12:24 ID:hfrti5Ii0(1) AAS
randerて
430: (ﾜｯﾁｮｲ c1ba-3WDN) 03/09(日)10:22 ID:4G6sVQNz0(1) AAS
>>422
コンポーネントというより、質問のニュアンスだとフォーム部品ごとの出力オブジェクトか
制御フックのこと言ってるっぽいが
Reactはフォーム処理に関してSvelte、Vueにくらべたら糞性能というか、もともとが
深層ステート管理のためのライブラリだしな。複数のフォームを一発制御できる
useStateフックの書き方ググるかカスタムフックで作る
それかReact捨てて、簡単にリアルタイム制御できるVueかSvelteで作るかだな
どっちもストアライブラリ使わないとスパゲッティまっしぐらだがな
431: (ﾜｯﾁｮｲ d901-9PhM) 03/16(日)20:48 ID:tTfhwjnK0(1) AAS
>>386
商用サイトじゃないけど、学研グループの勉強サイトはAstroで書かれてるね
外部ﾘﾝｸ:manabitimes.jp
432: (ﾜｯﾁｮｲ 6b17-aFR6) 03/17(月)14:00 ID:jWjXnHtA0(1) AAS
芳根京子の公式サイトはNextだった
433: (ﾜｯﾁｮｲ ebdb-ALb0) 03/17(月)21:32 ID:wrJsj8Yz0(1) AAS
SvelteKitとても好きです。
434: (ﾜｯﾁｮｲ 1101-vsiE) 03/21(金)06:23 ID:/97bZQtT0(1) AAS
Astro触ってみたけどすごいなこりゃ
こんなのできるならよほど大規模なサービスでも無ければNext.jsは要らないのでは
435: (ﾜｯﾁｮｲ 4101-H5Hv) 03/21(金)08:43 ID:oycs/B450(1) AAS
Astroまだちゃんと触ったことないけど
Reactコンポーネントを将来、全く別のフレームワークのコンポーネント、例えば引数とレンダリング結果が同等の動きをする、コンパイルされたバイナリなんかに差し替えたりとか出来たら面白いな
436(1): (ﾜｯﾁｮｲ 41e4-LAUx) 03/22(土)21:59 ID:amqAprOd0(1) AAS
どうせAI任せになるから関係ない
近いうちにAIが直接SSGしたりWeb Assemblyを直接生成するようになるからフレームワークなんか消滅する
437: (ﾜｯﾁｮｲ 138a-h6PX) 03/22(土)22:19 ID:1zuGIIBA0(1) AAS
>>436
おまえの方が早く消滅しそう...
438: (ﾜｯﾁｮｲ b33d-UJeM) 06/10(火)00:46 ID:YuUkDZe90(1) AAS
Remix v3が大改造するみたいだな
従来のRemixはReact Router v7になってRemix v3はpreactベースになるということか
439: (ﾜｯﾁｮｲ e2b4-95xj) 06/30(月)02:27 ID:34cw/UqT0(1) AAS
スレチだったらごめん
オンライン麻雀ゲームを作成しようと構想(妄想)してるんだけど、
いまから新規に作るならフロント側にはReactかVue.jsか、あるいは他のライブラリのどれを使えばいい?
先駆者 (書籍も出してる) は
> jQueryでないと美しく実装できない
外部ﾘﾝｸ:blog.kobalab.net
って言ってるけど、Webゲームのクライアントは特殊ってこと?
440: (ﾜｯﾁｮｲ e251-+g0z) 06/30(月)03:09 ID:6K91Vfp30(1/6) AAS
その記事の人はReact使ったことがないから知識ゼロなんだろ
そもそも状態管理をして宣言的にUIを構築するんだからむしろReactのほうがスッキリ書ける
jQueryおじさんという化石思考に惑わされてはいけない
441: (ﾜｯﾁｮｲ e251-+g0z) 06/30(月)03:19 ID:6K91Vfp30(2/6) AAS
> 宣言的アプローチでは「打牌中」の状態を描画できない
いや、Reactでは描画のための状態はUIコンポーネント内部に保持することでコアロジックを汚染することなく打牌中のような中間状態を美しく描画することができる
442: (ﾜｯﾁｮｲ e251-+g0z) 06/30(月)03:23 ID:6K91Vfp30(3/6) AAS
Reactは宣言的UIは最終的な状態だけを表現するということではない
アニメーションやユーザー操作に伴う一時的な状態、ここでは打牌中もコンポーネントの内部状態やコンテキストAPIとかで管理できる
isPlayingAnimationのようなブーリアン型の状態を用意し、アニメーション中はtrueに設定し、アニメーションが終了したらfalseに戻す
打牌中の牌の位置や動きに関する情報を状態として持ち、その状態に基づいてCSSアニメーションを適用する
443: (ﾜｯﾁｮｲ e251-+g0z) 06/30(月)03:27 ID:6K91Vfp30(4/6) AAS
> Majiang.ShoupaiはAIの思考ルーチンでも使用します。ここに描画の都合の「打牌中」などという状態を持ち込むとしたら、それは設計として誤っています
Reactでも描画に関わる状態とアプリケーションのコアロジックに関わる状態は分離して管理するのが一般的
コアロジックの麻雀の牌姿やルール進行を司る部分は、Reactコンポーネントからは独立した純粋なJavaScriptクラスや関数として実装するのが普通
444: (ﾜｯﾁｮｲ e251-+g0z) 06/30(月)03:33 ID:6K91Vfp30(5/6) AAS
> イベントハンドラ設定は描画処理と分離すべきである
Reactの設計思想はコンポーネントが自身の描画とそれに関連するイベントハンドリングをカプセル化すること
「対戦相手の手牌にイベントハンドラは不要だし、牌譜再生にも打牌のためのイベントハンドラは不要」という点についてはReactのコンポーネント設計で柔軟に対応できるからまったく問題なし
isInteractive: booleanなどを渡すことでイベントハンドラの有無を制御できる
牌譜再生時にはイベントハンドラが不要なモードでコンポーネントを描画すればいいだけだし
445: (ﾜｯﾁｮｲ e251-+g0z) 06/30(月)03:43 ID:6K91Vfp30(6/6) AAS
> JSXを使う局面がない
> HTML に雛形として埋め込まれた「牌を表現するDOMノード」をコピーし差し込むことで実現しています。
Reactをまったく知らないからこんな恥ずかしことを堂々と言えるんだろう
こいつのもっとも無知なところだな
Reactは宣言型だからコピーするというコードを書くことすら不要なわけ
446(1): (ﾜｯﾁｮｲ eb7c-Qyzi) 07/01(火)16:48 ID:SIBQ1DK00(1) AAS
牌なんてCanvasに直接描画すりゃエフェクトも自在だし変にエレメントにデータ持って
重くなることもなくていいんじゃね？って思うのは俺だけなのか
447: (ﾜｯﾁｮｲ 62ad-i45a) 07/03(木)12:01 ID:+b4ZnWKa0(1) AAS
>>446
俺もこう思う
そもそも牌をhtml要素とCSSで描画すること自体が微妙だよね
そういう意味だとjQueryでもReactでもなくてCanvas系のフレームワーク使ったほうが良いんじゃないかな
448: (ﾜｯﾁｮｲ 9f00-N87D) 07/06(日)06:18 ID:GxvgQzqn0(1) AAS
宣言的UIに慣れるとCanvas全体を命令的に描画するのがあまりにもダル過ぎる
449: (ﾜｯﾁｮｲ 9f4f-BzvG) 07/06(日)11:52 ID:77BphujQ0(1) AAS
Canvas上の各表示オブジェクトを
Reactやビューで
あたかもHTMLの要素の様に操作できる（CSSプロパティ設定できる）
ライブラリってあるのかな。
450: (ﾜｯﾁｮｲ 1f3d-duEB) 07/06(日)12:44 ID:8Iwql4w40(1) AAS
flutterでよくね
451: (ﾜｯﾁｮｲ 9701-5BqU) 07/09(水)16:01 ID:2rb1ksuv0(1) AAS
実際のゲーム開発で宣言的UIが採用されることってあるの？
452: (ﾜｯﾁｮｲ 877c-Bd2j) 07/20(日)07:51 ID:SQq4ZXml0(1) AAS
設定画面とかチュートリアルなら、まあ宣言的UIを使うもアリ。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.936s*