Vue vs React vs Angular vs Svelte Part.9

**デフォルトの名無しさん** · 2022/01/16(日) 16:06:14.27

Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
Svelte
https://svelte.dev/

※前スレ
Vue vs React vs Svelte Part.7
https://mevius.5ch.net/test/read.cgi/tech/1610901677/
Vue vs React vs Angular vs Svelte Part.8
https://mevius.5ch.net/test/read.cgi/tech/1621744952/

★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。

**デフォルトの名無しさん** · 2022/01/16(日) 16:06:33.48

こっちが本スレ

**デフォルトの名無しさん** · 2022/01/16(日) 16:09:20.44

乙

**デフォルトの名無しさん** · 2022/01/16(日) 16:10:01.28

ざまぁあぁｗｗｗ

**デフォルトの名無しさん** · 2022/01/16(日) 16:19:39.28

どういう連鎖アボン正規表現入れたら快適になるかな？

**デフォルトの名無しさん** · 2022/01/16(日) 19:21:09.12

Next.jsはええぞ。SSRもSSGもISRもSPAも行ける

**デフォルトの名無しさん** · 2022/01/16(日) 21:32:04.77

SPAでいるか？

**デフォルトの名無しさん** · 2022/01/16(日) 22:25:50.12

そもそもvsだから変なの湧くんじゃね
普通にタイトル4つの総合でいいやん

**デフォルトの名無しさん** · 2022/01/16(日) 23:18:41.06

このスレが、いつもの荒らしが立てたもの！
いつもテンプレに、自分が有利なように追加してる

>1
>★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
>★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
>Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。

多くのPython のスレでも、いつもテンプレを変えている。
>・当スレにRubyのソースコード類を書くことを禁ず
>・Ruby等、Pythonではないプログラミング言語での回答類・質問を書くのも禁止
>・「Ruby では」「Rubyでは」「Rails」正規表現→「^クソチョンw$」をNGワード登録推奨

多くのJavaScript のスレでも、
jQuery, Lodash を禁止とか書いている

いつも、この荒らしがスレを立てて、テンプレを変えてくるので、
漏れらは荒らしの立てたスレから、正規のスレへ誘導してきた

9 · 2022/01/16(日) 23:21:41.36

このスレの削除依頼を出して、下の正規のスレへ移ってください！

Vue vs React vs Angular vs Svelte Part.9
https://mevius.5ch.net/test/read.cgi/tech/1642316327/l50

**デフォルトの名無しさん** · 2022/01/16(日) 23:50:47.88

ここで良い
向こうのスレは無関係なjQueryが唐突に入れられている

**デフォルトの名無しさん** · 2022/01/17(月) 00:11:09.64

向こうのスレは荒らしが立てた事を証明する捨て台詞がご丁寧にも書いてあるしね

**デフォルトの名無しさん** · 2022/01/17(月) 12:41:22.76

Reactはいいフレームワークだけどフロントって非同期使いまくるのに非同期の扱いが残念なのがちょっとね
他のSPAフレームワークって使った事ないけど非同期はどうなんだろう

**デフォルトの名無しさん** · 2022/01/17(月) 12:48:41.83

>>13
まず最初にお前が理想のフレームワークをいえ
Reactが残念なんじゃなくて
お前が非同期処理を理解できないだけだろ

まるでプログラミングを勉強したくないけど
なんか凄いものを作りたい、簡単に使える言語ないの？って
言ってるようだ

**デフォルトの名無しさん** · 2022/01/17(月) 13:01:07.87

>>14
レベル低すぎて相手するのも面倒なレスだけどreactが非同期ニガテなのは常識だよ
今までずっと正解らしい正解がみんなで共有できてなくてuseState、useEffectで分かりにくい処理を地道に書く、それらをラップするオレオレフックを作る、別のサードパーティフレームワークを付け足して使う、などなどそれはもう、迷走しまくってた
reactが世に出てもう何年経ったかわからんが、最近になってようやっと公式が重い腰を上げて、Suspenseに取り組み始めたけど、これだって今までよりはマシかもって程度であって、けして非同期が楽だとは言えない代物

そんで楽してすごいものを作りたい、というのはフレームワークの存在意義そのものであって、それを否定するのは何も理解してない車輪の再発明マニアだけだ

**デフォルトの名無しさん** · 2022/01/17(月) 13:01:29.47

>>13
そうかなぁ、useEffectで非同期拾ってstate変えたら全部スパッと変わるんだから、やりやすいと思う。useEffectは非同期関数食ってくれないけども

**デフォルトの名無しさん** · 2022/01/17(月) 13:09:21.87

と思ったけどそういうレベルの話ではなさそうだな

**デフォルトの名無しさん** · 2022/01/17(月) 13:13:12.62

>>16
いや、あれはわかりにくい
依存関係とか諸々含めて、誰でもすんなり理解して間違いなく使える仕様とは思えん
必ずどこかでハマるように出来てる
つうか、完全に理解したとしても冗長な記述が多すぎる

reactの仕様を大きく変えてasync JSXタグをサポートするべきだと思うんだよな
例えばこういうの↓
const FooView = async () => {
try {
const foo = await fetchFoo();
return <View>
<Text>{foo.name}</Text>
<Text>{foo.age}</Text>
<View>
}
catch (e) { return <ErrorView error={e} /> }
}

もし仮にここまで出来れば俺は「reactは非同期が楽」と言っていいと思うぞ

つーかこんなんreactの開発者レベルならとっくに気付いてる筈なんだが
怠慢なのかわからんが、非同期をずっと放置し続けてきた

**デフォルトの名無しさん** · 2022/01/17(月) 14:23:54.47

>>18
あーなるほど。確かにそこまでサポートされてれば楽かもな～。
待ってる間はFragmentが入るようになってれば（多少柔軟性は落ちても）同期部分とも連携は取れると。
俺はそこまでは要らないかな。でもなるほどね

**デフォルトの名無しさん** · 2022/01/17(月) 14:33:09.18

>>18
いや待て、そこでfetchしたら駄目じゃね？

**デフォルトの名無しさん** · 2022/01/17(月) 15:31:40.92

>>20
機能を提供するのはよいぞ
どう使うかは宗教のもんだい

**デフォルトの名無しさん** · 2022/01/17(月) 18:31:36.68

fetchFooが何度も走るからその場所はマズくね？

**デフォルトの名無しさん** · 2022/01/17(月) 18:44:23.62

useSWRを使ってみるとか
(まだ使ったことないけど)

見た感じそれなりに使いやすそう?

import useSWR from 'swr'

function Profile() {
const { data, error } = useSWR('/api/user', fetcher)

if (error) return <div>failed to load</div>
if (!data) return <div>loading...</div>
return <div>hello {data.name}!</div>
}

**デフォルトの名無しさん** · 2022/01/17(月) 19:25:32.08

>>23
単純なケースでしか通用しない気がするけどいけるんかな？

**デフォルトの名無しさん** · 2022/01/17(月) 19:25:53.20

>>18
コンポーネントにガッツリ副作用入れてどうすんだよw

**デフォルトの名無しさん** · 2022/01/17(月) 23:06:59.06

はっはっは、だから言ったろ
お前が非同期処理を理解してないって

想像した通りに動いてくれるわけじゃないのだよ
不可能なことは、不可能

**デフォルトの名無しさん** · 2022/01/17(月) 23:11:50.20

>>18
そんなバグの温床になりそうなコード書くくらいなら、
componentDidMountでfetchして、素直にsetStateしとけ
それで済む話だろ

9 · 2022/01/17(月) 23:50:21.01

このスレは、荒らしが立てたスレです。
まともな人は、移動してください！

>>9-10
を参照

**デフォルトの名無しさん** · 2022/01/18(火) 00:00:44.87

>>26
具体的な事言わずに批判だけするとか……老害かな？

**デフォルトの名無しさん** · 2022/01/18(火) 00:30:02.59

>>22
パラメータが変わらなければ同じpromiseが再利用されるので問題ない

**デフォルトの名無しさん** · 2022/01/18(火) 15:39:09.53

>>30
fetchFooは（シングルトンみたく）何度呼び出しても同じPromiseを返すって事か。それなら確かに問題ない。
そう云うPromiseを作るhookと待ってる間はFragment（か何かをDOMに接続）、あとエラー時用のインターフェイス（Promise関連だからcatchメソッドで良いか）が必要、と。
う～ん、俺はuseEffectでいいやw

**デフォルトの名無しさん** · 2022/01/18(火) 19:50:02.62

>>31
そうじゃない
react側で不要な再実行を避けてpromiseを再利用するように作るだけ

**デフォルトの名無しさん** · 2022/01/18(火) 20:36:42.52

FooViewが発行したPromiseインスタンスを再利用するという事？

**デフォルトの名無しさん** · 2022/01/19(水) 19:07:29.30

lazyとSuspense、ErrorBoundaryを使う
データ単位で制御したいならRecoilを組み合わせる（Atomのdefaultやselectorで非同期処理）
>>13はRecoilとConcurrentModeがまさにそれ
あと>>16の"非同期関数食ってくれない"という表現が良く分からないのだが、即時関数を使えば良いという話ではないのだろうか

**デフォルトの名無しさん** · 2022/01/19(水) 19:25:26.21

>>34
useEffectの引数に直接async function入れられなくて少し不便ってだけの話で特に特に問題無いから無視してええよ

**デフォルトの名無しさん** · 2022/01/19(水) 20:05:38.12

<ErrorBoundary onErrorComponent={ErrorView} >
<Suspence fallback={<Loading />}>
<Text>{props.foo.read().name}</Text>
</Suspence>
</ErrorBoundary>

一見すると良さそうだけど間違ってる
Textをラップするコンポーネントを作ってやらんとダメ
なんか書くものが多くてめんどくさい
後は純粋に醜い
処理フローの制御をタグで書きたくない

recoilって正直なとこContext APIやReduxより多少スマートだけど根本的なとこはあんま変わってないと思う
というかrecoilって基本は状態管理ライブラリだし非同期のめんどくささとはまた別の話では？

**デフォルトの名無しさん** · 2022/01/19(水) 21:22:56.22

ラッパー高階関数なりhookでも書けばええんちゃうか……。
目的を最小のコードて書けるライブラリは用途特化ライブラリであって、汎用たり得ないと思うんだ。

**デフォルトの名無しさん** · 2022/01/19(水) 22:03:34.62

Suspenseでラップされたコンポーネントで使われているAtomで
非同期処理を実行している間はfallbackが呼ばれるため、loading stateが不要であったりと
RecoilはConcurrent Modeを意識した作りになっている
というのを踏まえた上で、Reactはv18から非同期でコンポーネントを扱う場合は
Suspenseでラップする形を押していくようなので
その手法が嫌なら何とも言えない（あなたの提案が悪いというわけではなく、Reactの方針的に）

**デフォルトの名無しさん** · 2022/01/20(木) 02:46:03.95

そうやって過剰な設計をするならReactとかの
フレームワークは重くなるんですよね

**デフォルトの名無しさん** · 2022/01/20(木) 07:10:36.24

重いってのは色んな要素や意味があるし、かなり曖昧表現だな。
スピードテストベンチマークも増えて、一時期に比べればみんな速度を意識しだして、Webって早くなってきたよ。

**デフォルトの名無しさん** · 2022/01/20(木) 12:12:04.67

>>40
帯域制限中の格安スマホ

**デフォルトの名無しさん** · 2022/01/20(木) 12:21:04.70

ここ数ヶ月で重すぎてブラウザバックした記憶はqiitaだけだな
あれは何のフレームワーク使ってるんだろ

**デフォルトの名無しさん** · 2022/01/20(木) 12:25:07.74

qiitaはスマホが発熱するレベルで熱くなる

**デフォルトの名無しさん** · 2022/01/20(木) 12:47:36.33

>>41
なる程。となると容量だな。
帯域制限状態を256kbpsとするとminify+gzipなReact(ReactDOM含む)で36KBなら1.125秒か。時間かかるっちゃかかるけど、この速度域だと画像すら重すぎてそれ以前の問題だなw

**デフォルトの名無しさん** · 2022/01/20(木) 12:52:08.95

結局のところ単純で速い方がいい
reactでゴテゴテに装飾したSNSより伍ちゃん戦ブラが良いんだな

**デフォルトの名無しさん** · 2022/01/20(木) 12:58:52.80

今のSNS大抵レスポンス良いぞ

**デフォルトの名無しさん** · 2022/01/20(木) 13:02:02.17

そもそも目的や規模感、場合によってはチームの習熟度で不足にも過剰にもなる
結局は毛嫌いせず、状況に応じて使い分ければ良いだけの話

**デフォルトの名無しさん** · 2022/01/20(木) 16:56:37.93

>>42
あれフレームワークっていうより遅延ローディングの問題な気がしてる
バックエンドが詰まってる印象

**デフォルトの名無しさん** · 2022/01/20(木) 20:33:47.49

>>42
> ここ数ヶ月で重すぎてブラウザバックした記憶はqiitaだけだな

普通にネット見ていてもReactのような
重量系フレームワークを使ってるところなんて殆どないからね
QiitaはReact使ってるみたいだけど、一体あれのどこに必要なんだろうか

**デフォルトの名無しさん** · 2022/01/20(木) 20:53:35.92

とりあえずSSG使ってCDNにpushすれば解決するのだがそういう改良する人材もいないんだろうな
元々優秀な技術者集団がいたはずだけど
技術のコモディティ化でその人たちも凡人になったのか
人がいなくなったのか

**デフォルトの名無しさん** · 2022/01/20(木) 20:54:50.03

何をもって『重量系』？

**デフォルトの名無しさん** · 2022/01/20(木) 21:04:59.02

>>50
Qiitaの親会社の偉い人に合った事あるけど、技術や技術者の事なんてどうとも思ってなさそうな人だったよ。それからしばらくしてあの炎上騒ぎが起きて、さもありなんと思った。

**デフォルトの名無しさん** · 2022/01/20(木) 23:08:25.65

>>49
Zenn、Twitter、Instagram、Facebook、LINE、Yahoo、ZOZO、はてなブログ、AmazonのAWSの管理画面などなど
これらはフロント全体もしくは部分的にReactだけど？
Googleは多くのサービスでAngularだし

普段ネットで見てんの？

**デフォルトの名無しさん** · 2022/01/20(木) 23:31:12.23

掲示板のレスの1つ1つに開閉式のメニューをつけるのってどうやるんだ？
下はyahooニュースだが、レス一覧の「非表示・報告」ってとこ押したら出てくるような奴
https://news.yahoo.co.jp/articles/5d52fe0f406f1aa3e9f2263f58966858786bf8a0/comments
vue だったらレス一個一個にコンポーネントマウントしないといかんのか？？

**デフォルトの名無しさん** · 2022/01/20(木) 23:36:53.55

>>54
VueでもReactでもAngularでもそう

**デフォルトの名無しさん** · 2022/01/20(木) 23:43:22.25

>>55
なるほど。内部的には各ボタンにイベントリスナーつけるわけだから当然と言えば当然ではあるか。
サーバ側ではレスをPHPでforeach で回して出力するけど、そのタイミングでvueがマウントするためのコードを生成する必要があるってことなのか？

**デフォルトの名無しさん** · 2022/01/20(木) 23:44:48.93

>>53
noteなんかはVue使ってるしな

**デフォルトの名無しさん** · 2022/01/20(木) 23:46:19.28

vue選んだ会社はどうするんだろうか
オワコンまっしぐらなのに

**デフォルトの名無しさん** · 2022/01/20(木) 23:56:11.92

生田勇人(39)
高知市朝倉中学校卒業
恐喝と暴行、偽証、傷害容疑で逮捕、起訴。
://togetter.com/li/1227954
://pbs.twimg.com/media/DbUOGw1VQAAqJcx.jpg:large
://i.imgur.com/tuUldwv.jpg
://www.youtube.com/watch?v=UyNXI8usCrM
取り調べで「事実無根」と容疑を否認。
卓球所に松岡学(39)と出入りし賭け試合を被害者に強要、一回ミスったら1000円払えと発言。
2万円を取ろうとした。親にチクったらただじゃ済まんぞと被害者の胸倉をつかみ壁に叩き付け2000円を脅し取り、後日腹を複数回殴った疑い。
生田勇人の両親も被害者の親にたかっていた。

**デフォルトの名無しさん** · 2022/01/21(金) 00:01:35.86

>>56
一例だけど、ページが読み込まれてCommentListコンポーネントがマウントされたタイミングでサーバからコメントを取得して
メニューを持ったCommentコンポーネントをcomments.mapで回す
この時のcommentひとつひとつをCommentコンポーネントのpropsに渡して描画していく

**デフォルトの名無しさん** · 2022/01/21(金) 00:48:10.29

Vueはそもそもの背景にAngularがあるのに
Composition登場以降、React寄りになったのが何とも
今のVueはどこに向かっているのか分からん

**デフォルトの名無しさん** · 2022/01/21(金) 00:54:42.07

>>54
https://codesandbox.io/embed/dark-dawn-0sk8t?fontsize=14&;hidenavigation=1&theme=dark
↑ でけたで！！！
VueじゃなくてReactやけども

みんなもよかったらコードレビューしてや！

これ思たんやが、メニューの中身共通やんか
ヤフコメの仕様に合わせて同時に複数開けるようにしたからこうしたけど、同時に複数開かなくてもいいっていう仕様やったらばよ
各コメントのカードの中にメニュー含めず、メニューは外に出して1個だけ記述する方が無駄なさげな気するんやがどないなん
コード的には同じもんが複数あるってイメージが湧いてしまうわけやが、基本マウントされてないから別にええんか
意味わからんかったらすまんやで

**デフォルトの名無しさん** · 2022/01/21(金) 02:20:49.29

その考え方で良いと思う
表示非表示といっても、仮想DOMのおかげで差分が更新されるだけなので
ひとつのメニューを座標などを保持してまで使い回すメリットがほとんどない

表示されているメニューをひとつだけとするなら
メニューを透明なBackdropと共に描画して、メニュー外がクリックされた場合はメニューを閉じるようにする
これはMUIのBackdropやMenuコンポーネントを参考にすると分かりやすいと思う
他にはグローバルステートにして、ひとつが表示状態となった場合、他が非表示となるようにする
これはReduxで複数のダイアログの状態を扱う場合なんかに使われたりする
規模感にもよるが、今だとRecoilで管理するのがシンプルでおすすめ
他にはonMouseLeaveで非表示にするのもアリかもしれない

**デフォルトの名無しさん** · 2022/01/21(金) 02:28:51.97

>>60
やっぱりコメント自体を非同期で取得してくるしかないのかあ・・・。
現在の仕様やと、サーバ側でコメントをhtml生成してからレスポンス返しているから、作り直すの大変やなあ。
開閉メニューだけをvueでコンポーネント作ってってことをできんかと思ってたけど厳しいかもなあ。
ちなみに生JSで開閉メニューを作成済みなのだが、それをvue に書き換えたかった。

>>62
うおおおおおおおおすげええええ
でもreactわからん・・・・・・vueでも同様のことができるんやろなあ。
メニューの中身は共通やけど、yahooの例で言えば非表示と報告やからそのコメントを特定できるIDみたいなものをサーバに送るために仕込んどかんといかんのや。。。

**デフォルトの名無しさん** · 2022/01/21(金) 05:23:06.12

>>42
Railsは、GitHub, Airbnb, Disney, Hulu, SoundCloud, Shopify といった世界的に有名な企業や、
日本国内でも、note、クックパッド、freee、マネーフォワード、Progate、Qiita などで使われている

2021年10月には、Railsを使い続ける宣言をしている、GitLab が上場し、時価総額は約1.9兆円！

時価総額1兆円ぐらいまでは、Railsで行ける。
その後、Go へ移行する

ここで、URL を入力して、サイト分析できる
https://builtwith.com/

65 · 2022/01/21(金) 05:34:51.10

女の娘が1人で起業した、食べチョクは、Rails, React

食べチョクは、生産者と消費者を結ぶ、農林水産物の直販サイトだけど、
コロナで取引量が30倍になったとか

海外のRailsでは、ほとんどReactが多い

ただ日本は特殊で、YouTube で有名な、雑食系エンジニア・KENTA のサロンでも、
未経験者の転職用にはReactよりも、Vue.js を使うように指示している

65 · 2022/01/21(金) 06:17:34.93

Rails では、命名規約だけのフレームワーク・Stimulus もある。
イベントの書き方だけを決めている

Railsの作者・DHH が、デモなどでよく使う

1つのDOM に、コントローラーを複数設定できる
<div data-controller="hello goodbye"></div>

また、同じコントローラーを複数のDOMに設定できる
<div data-controller="hello"></div>
<div data-controller="hello"></div>

つまり、多対多

アクションはクリックで、helloコントローラーのgreet メソッドを呼ぶ
<button data-action="click->hello#greet"></button>

ターゲットを設定すると、this.nameTarget, this.outputTarget で、
ターゲットとなるDOMを取得できる

static targets = [ "name", "output" ]

greet() {
this.outputTarget.textContent =
`Hello, ${this.nameTarget.value}!`
}

ターゲットとなるDOM。helloコントローラーのname・outputターゲット
<input data-hello-target="name" type="text">
<span data-hello-target="output"></span>

**デフォルトの名無しさん** · 2022/01/21(金) 07:05:45.77

>>62
ややこしいstate管理してるな、コメントカードをコンポーネントにしてstate持たせりゃコード半分で済むやんけ、と思ったらメニュー使いまわそうとか考えてたのね。なるほど。
細かい所言うとfetchはPromiseな方がそれっぽい雰囲気になってええんちゃう、くらいかな。

>>64
html生成をjson生成に変えるだけだから楽なもんよ（悪魔のささやき）
Vue使う使わない以前に、コメントにはID付けた方が良いし、コメントは生htmlじゃなくてjsonあたりから都度生成の方が良いと思う。

**デフォルトの名無しさん** · 2022/01/21(金) 08:28:34.38

プライベートなシステムの管理画面で複雑なReact使ってるけど重くもなくむしろ速い
どちらかというとサーバーにアクセスするAPIのほうが遅くてローディングアイコンくるくるしてる
閉鎖的なシステムだから業務ロジックはバックエンドではなくほぼtsで書いてるから処理は速い

**デフォルトの名無しさん** · 2022/01/21(金) 11:11:34.46

>>53
お前のインターネットの世界には
それだけしかないのか？

**デフォルトの名無しさん** · 2022/01/21(金) 11:15:00.08

コンピュータ用語と関係ない用語で検索してTOP10のサイトが
どのフレームワークを使っているか確認してみればいい
例えば「ネコ」で検索するとかな

**デフォルトの名無しさん** · 2022/01/21(金) 11:46:13.84

殆どない、に対してのレスだから
適当に列挙してもこれだけあるよ？って話でしょ

**デフォルトの名無しさん** · 2022/01/21(金) 11:54:33.96

適当に列挙したと言う割に
有名なコンピュータ関連の会社に偏ってるから
ダメだって話をしてる

適当に列挙させるために
コンピュータ用語と関係ない用語で
検索したサイトで調べろと言ってる

**デフォルトの名無しさん** · 2022/01/21(金) 12:09:01.10

ま～たあんたか。今日もご苦労さん

**デフォルトの名無しさん** · 2022/01/21(金) 12:16:03.07

そんな謎調べ物させる前に重いサイト列挙すりゃ済む話やろ

**デフォルトの名無しさん** · 2022/01/21(金) 12:45:58.84

ループ内でuseState使えるようにはできないのかなー
これ完全にフレームワーク設計の欠陥だよね

自分も>>62みたいな書き方をよく書くけど配列から子コンポーネントに渡すpropsに変換する手間がかかって面倒くさい
しかも配列の1要素を変更しただけで配列全体が変更されたとみなされてイベントハンドラが更新されて子コンポーネントも更新されるのが気になる

純粋な子コンポーネントをラップしてstateを持たせたコンポーネントをプライベートスコープに書いて
そのラップコンポーネントを使うって手も有るけどこれはこれでめんどくさい

かと言って子コンポーネント自体に副作用を持たせるとテストがめんどくさくなって再利用性も下がる

**デフォルトの名無しさん** · 2022/01/21(金) 12:54:15.65

>>73
“殆どない”に対して”あるけど？”ってことなんだが大丈夫か？

**デフォルトの名無しさん** · 2022/01/21(金) 13:00:10.73

>>76
いや、仕組みを考えればなぜそういう仕様なのかはわかるよ

**デフォルトの名無しさん** · 2022/01/21(金) 13:00:46.06

ListやListItemなら再利用前提だけど
CommentListやCommentListItemとかになる固有だったりするから内部に状態を持たせたらいい
テストが大変、ってことならカスタムフックでロジックを分離すればいい

**デフォルトの名無しさん** · 2022/01/21(金) 13:10:35.79

>>78
仕組みの問題なのはわかるけど
利用者の立場を考えたインターフェースデザインになってないのはフレームワークとしては残念ポイントだね
本当に良いフレームワークはまず使いやすいインターフェースがあってそこに実装を合わせていく
「実装の都合のせいで関数トップレベルにしかフックかけません」ってのはそう言う意味では怠慢かな
「どこでも書けるように実装の方で勉強しました」こういう姿勢が必要