React と React Native のスレ

**デフォルトの名無しさん** · 2019/03/09(土) 21:29:27.97

Q. Reactってなんですか？
A. ブラウザで動くウェブアプリを作るJavaScriptフレームワークです

Q. React使えば、iOSやAndroidアプリも作れるのですか？
A. 作れません。（ブラウザでなら動きます）

Q. でも動くってきいたんだけど？
A. それはReactではなくReact Nativeです。

Q. React と React Native は同じようなものじゃないの？
A. 設計思想が同じなだけで、中身は全くの別物です。

Q. React Nativeで作ればブラウザで動くの？
A. 動きません。（動くようにするサードパーティ製のライブラリならあります）

Q. React と React Native でソースコード共通化できるの？
A. UIの部分は共通化出来ません。UI以外の部分なら頑張れば

Q. このスレはどっちの話題のスレなの？
A. 両方です。どっちの話題をしているかは文脈で判断してください

**デフォルトの名無しさん** · 2021/08/12(木) 03:23:50.10

>>108
受け答えから見て実力が低そう

**デフォルトの名無しさん** · 2021/08/12(木) 17:08:42.90

>>107
クラス記法はこういう欠点があるからなあ
ttps://speakerdeck.com/sonatard/coheision-coupling?slide=24

**デフォルトの名無しさん** · 2021/08/12(木) 17:57:27.67

大方の単細胞腦は、SQLDBとNoSQLDBの時がそうであったように
関数コンポーネントとクラスコンポーネントのどちらかに
絶対的な優劣をつけたがってんじゃね？

今回も関数コンポーネントがマッチする場合と、
そうでない場合がありそうに見える

とくに、関数コンポーネントは
コンポーネントのインスタンスが自由に扱えない（扱えなさそう）から
そういった処理の実装時に（React用で無いJSライブラリを無理やり動かしてたようなケースとか）
トラブりそうな気がする

**デフォルトの名無しさん** · 2021/08/12(木) 18:16:18.47

典型的な「分かってないことが分かってない」ヤツ

**デフォルトの名無しさん** · 2021/08/12(木) 18:29:54.23

優劣はどうでもよくてクラスコンポーネントは互換性のために残されてるだけってのがReactの立場
新しい機能の中には関数コンポーネントからしか使えないものが出てるしこれからも増える
そもそも対等な選択肢ではないから議論する価値がない
状況に合わせて適応するってのが一番大事

**デフォルトの名無しさん** · 2021/08/12(木) 18:43:59.17

>>113
>> 互換性のために残されてるだけってのがReactの立場

なんと！(; ･`д･´)

**デフォルトの名無しさん** · 2021/08/12(木) 18:53:29.47

今の公式ドキュメントやチュートリアルは古くてクラスコンポーネントが大きく扱われてるのが本当に良くない
それはReactチームも分かってるからドキュメントを全面的に書き換えてる最中
もちろん関数コンポーネントとHooksメインで

**デフォルトの名無しさん** · 2021/08/12(木) 19:01:46.19

>>115
なんと！(; ･`д･´)

**デフォルトの名無しさん** · 2021/08/26(木) 15:41:55.94

フック初心者ですが
「フックは関数のトップレベルのみで呼び出してください。」
とあります。この関数は関数コンポーネントの意味で合ってますでしょうか？

**デフォルトの名無しさん** · 2021/08/26(木) 15:51:22.45

<Button1>と<Button2>で
それぞれ内部でuseStateを使ってたら

<Button1>
<Button2/>
</Button1>

はNGになるのでしょうか？

**デフォルトの名無しさん** · 2021/08/26(木) 16:38:00.65

>>117
> この関数は関数コンポーネントの意味

違う
ifやforなどの制御構造の内側から呼び出すなということ
要するに関数コンポーネントの呼び出しごとにhookが実行されたりされなかったりしてはいけない
なので?:や&&などと組み合わせるのもダメ

**デフォルトの名無しさん** · 2021/08/26(木) 16:39:25.72

>>118
それはOK
それぞれのコンポーネントは独立してるから問題ない

**デフォルトの名無しさん** · 2021/08/26(木) 16:45:57.37

>>120
有り難い！

しかし判り辛いですね
お題目だけだと
公式に具体例を上げてくれないと
勘違いしそう...

**デフォルトの名無しさん** · 2021/08/27(金) 13:34:41.69

hookの実行順でレンダリング毎の同一性を保証してるってわかってれば当たり前のことなんだけどね

**デフォルトの名無しさん** · 2021/08/27(金) 13:54:27.15

順番で状態を管理してるって一昔前の考えだと
なんだそりゃって感じになるんだけど
そもそも自分で管理するのはクソだから
全部フレームワークに任せちゃえってなってる
React凄い

**デフォルトの名無しさん** · 2021/08/27(金) 15:19:14.34

翻訳の問題かもしれんけど
「関数のトップレベル」という表現が判りずらい
「関数内部の最初の行あたり」で良くないか？

**デフォルトの名無しさん** · 2021/08/27(金) 15:45:49.48

function Foo(props) {
　if (props.flag) useEffect(...)
　...

最初の行だけどアウト

**デフォルトの名無しさん** · 2021/08/27(金) 15:48:30.00

「同じフックが常に実行されるようにすること」
これでよくね？

**デフォルトの名無しさん** · 2021/08/27(金) 15:49:19.59

関数のトップレベルの訳としての話しだよ(´Д`)

**デフォルトの名無しさん** · 2021/08/27(金) 15:57:29.79

モジュールのトップレベルもわからない？
それじゃトップレベルawaitも分からないしJSやるの無理やろ

**デフォルトの名無しさん** · 2021/08/28(土) 04:17:28.74

useCallback これっている？
fnのMemoならMemoってキーワードも名称から抜けてるし
useMemo(() => fn, deps) と同じならなおさら...

**デフォルトの名無しさん** · 2021/08/28(土) 04:35:56.44

fnをファットアローでインラインに書いてみ

**デフォルトの名無しさん** · 2021/08/28(土) 04:42:56.91

うー－ん！初学者だからなのか意味わからんです

**デフォルトの名無しさん** · 2021/08/28(土) 04:46:30.48

useCallback(fn, deps) が useMemo(() => fn, deps) こう書けるって事なんじゃないですか？

**デフォルトの名無しさん** · 2021/08/28(土) 04:54:08.75

useCallback((event) => {...}, deps) を useMemo(() => (event) => {...}, deps) って書きたいかって話

**デフォルトの名無しさん** · 2021/08/28(土) 05:10:24.97

>>133
良い！
そっちのが良い！

fnのメモなのに、useMemoCallback()になってないので直観的に思えない
初学者だと、ぱっと見CallbackするにはuseCallback()が必須に見える
理由はMemoの文字が入ってないから

**デフォルトの名無しさん** · 2021/08/28(土) 06:24:50.37

それ言ったらuseMemoなんてuseState使えばいいし内部でstate使ってるのにuseNemoStateじゃないの直感的じゃないよね

**デフォルトの名無しさん** · 2021/08/28(土) 08:24:29.02

useCallback だと名称から、
コールバック使いますよ！の宣言に見えると言っている

実際はコールバックをメモしますよ！だから
コード読むとき直感的でないと言っている

実際、初学者で関数コンポネント内でコールバックを定義するときは
useCallback()を使わなければならないと思いこんでいる人が少なからず居ると思う

**デフォルトの名無しさん** · 2021/08/28(土) 10:18:42.44

Ionicと比べた場合のReact nativeのメリットはアプリの動作速度が速いところ？

**デフォルトの名無しさん** · 2021/08/28(土) 10:19:30.77

ageてしまって申し訳ない

**デフォルトの名無しさん** · 2021/08/28(土) 10:59:30.05

>>136
初学者は
> useCallback()を使わなければならないと思いこんでいる
で丁度いい

**デフォルトの名無しさん** · 2021/08/28(土) 11:35:50.02

>>139
その心は？

**デフォルトの名無しさん** · 2021/08/28(土) 12:30:31.08

>>140
不要なuseCallbackを書いても実害はない
超大規模ならチリツモでパフォーマンスに影響あるかもしれないが初学者には関係ない
対して必要なuseCallbackを忘れるとuseEffectやReact.memoに影響しうるが初学者には気付きにくい
最初は愚直にuseCallback書いて後から不要なケースを学べばいい

**デフォルトの名無しさん** · 2021/08/28(土) 13:47:14.15

>>141
なるほど！
その意味であえて関数名もそうしたんだろうか...

**デフォルトの名無しさん** · 2021/08/28(土) 23:14:15.55

https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889
"カスタムフックは技術的にはReact機能ではない" って

ステートレス関数に状態を保持する機能が
jsに元よりあるという事でしょうか？

**デフォルトの名無しさん** · 2021/08/28(土) 23:39:41.08

カスタムフック===ユーザー定義フック
利用者(アプリケーション)で定義するものであってReactが提供する機能ではない

**デフォルトの名無しさん** · 2021/08/29(日) 00:17:55.75

>>144
それは了解してた！（質問を間違えた！）

フックを実現する技術（ステートレス関数に状態を保持する機能）は
ＪＳに元からあるという記述が公式にあったようにおもうのだけれど、
それは何？って事が言いたかった...

**デフォルトの名無しさん** · 2021/08/29(日) 01:51:35.47

>>145
前のリンクの文意から推察するに、フックはreactの特別な機能じゃなく
JSのクロージャーと array.push と array.pop とかで実装できるって事かな？

誤りありましたらご指摘下さい

**デフォルトの名無しさん** · 2021/08/29(日) 03:34:12.05

引用しろボケカス

**デフォルトの名無しさん** · 2021/08/29(日) 12:10:00.26

>>146
前のリンクの文意というのが

> Since Hooks are regular JavaScript functions, you can combine built-in Hooks provided by React into your own “custom Hooks”.

ら辺のことなら全然違う
Reactが提供する「組み込みフック」はJSの普通の関数だからそれを組み合わせて「カスタムフック」を作れると言ってるだけ
Reactが「組み込みフック」をどう実装しているかは触れてない
公式にあったという記述がなんのことかわからないがユーザー向けのドキュメントにReactの内部実装について書いてあるとは考えにくいので何か勘違いしてるんだろう

**デフォルトの名無しさん** · 2021/08/29(日) 12:12:17.85

もっともReactの組み込みフックがJS(+Flowtype)で実装されてるのは考えるまでもなく事実
詳しく知りたければソースを読めばいい
https://github.com/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberHooks.new.js

**デフォルトの名無しさん** · 2021/08/29(日) 13:18:38.44

>>148
>>145 で言ったように、それは最初から解ってる
聞きたかったのは、フック自体の実装方法だよ！

>>149
そりゃそーーだ

**デフォルトの名無しさん** · 2021/08/29(日) 13:41:49.73

>>150
お前さぁ・・・
フック自体の実装方法が知りたいならそう書けよ
無関係なリンクや公式のことを書くから「そんなことは書いてない」「お前の勘違い」「ボケカス」って話になるんだよ
つーか5ch開く前にすることあるだろ

**デフォルトの名無しさん** · 2021/08/29(日) 14:30:21.63

>>150
preactのソースを読め
わずか400行そこらでhooksを実装してる
俺がここ数年で見たコードで最も美しいコードだ
型もついてるからめちゃくちゃ読みやすい

https://github.com/preactjs/preact/blob/master/hooks

**デフォルトの名無しさん** · 2021/08/29(日) 21:46:55.62

>>152
(; ･`д･´)

**デフォルトの名無しさん** · 2021/09/18(土) 13:05:29.83

reduxでいままでやってたような処理ってhooksではuseContextとuseRuducerの組み合わせでやるってことであってます？

**デフォルトの名無しさん** · 2021/09/20(月) 00:13:37.74

最近react始めて、リスト構造を持つようなデータの画面表示は配列のmap関数使ってjsx書けってのは理解したんだが、配列の要素の持つデータを一か所でも変えると残りの要素は全く変わってないのに全てレンダリング処理し直すことになるよな？
reactが差分を見てくれるから実際のDOMに反映されることはないんだろうけど、変更された要素のコンポーネントだけにレンダリング処理させる方法ってないんか？

**デフォルトの名無しさん** · 2021/09/20(月) 00:18:04.28

>>155
keyを使え
チュートリアルにも乗ってたはず

**デフォルトの名無しさん** · 2021/09/20(月) 01:13:11.44

>>155
ならない

**デフォルトの名無しさん** · 2021/09/20(月) 02:01:14.08

>>155
要素を別コンポーネントにしてReact.memoする
その場合も156が書いてるようにkeyは必須
でも各要素のレンダリングがよほど重くない限り気にすることないと思うぞ

**デフォルトの名無しさん** · 2021/09/20(月) 08:25:15.93

>>156,157,158
㌧クス
もうちょい調べてみるわ

**デフォルトの名無しさん** · 2021/09/20(月) 12:16:07.93

>>159
リストの出力の場合
アイテム毎にkey必ず振らなければない
key無いのはバグだからね
コンソールにエラー出てるはず

**デフォルトの名無しさん** · 2021/09/20(月) 12:53:40.75

keyが必要なのは確かだがそれが影響するのはリアルDOMの更新
keyがないと

> reactが差分を見てくれるから実際のDOMに反映されることはないんだろうけど

が機能しなくなる
本来の質問であるコンポーネントのレンダリングを回避するのに必要なのはReact.memo

**デフォルトの名無しさん** · 2021/09/20(月) 18:39:05.51

ID:GKDt5rSn の的外れ感

**デフォルトの名無しさん** · 2021/09/20(月) 19:00:16.83

ストアに登録する前に1ヶ月テスト運用したいのですがそんなこと可能なんですか？
テストユーザーは50名程度の予定です

**デフォルトの名無しさん** · 2021/09/20(月) 21:16:44.39

それReact関係ないよね

**デフォルトの名無しさん** · 2021/09/22(水) 02:10:39.83

うーん、先に代弁してくれてる人もいる通り、自分が聞きたかったことを解消できるものじゃなかったな、keyを付けないかんてのは改めてよく分かったけど。memoに関しては配列でmap関数でjsx組立ててる場合に言及した解説サイトは見当たらんかったし、うまくいくかは一度書いて調べてみるかー

**デフォルトの名無しさん** · 2021/09/22(水) 15:53:36.27

>>165だけど、memo化して特定の子要素だけレンダリングが呼び出されるのを確認できたわ
ありがとう

**デフォルトの名無しさん** · 2021/09/25(土) 21:37:04.38

Vue.jsだと公式サイトからリンクにawesome-vueってのがあって
https://github.com/vuejs/awesome-vue
ここ（Components & Libraries）にVue向けのlibraryやcontrolのリストが列挙されてて大変便利なんですけど、
これのReact版とか無いですか？

**デフォルトの名無しさん** · 2021/09/25(土) 21:39:38.06

言った直後にまんまのがあった...
awesome-react
awesome-react-components

笑

**デフォルトの名無しさん** · 2021/09/25(土) 23:03:28.71

awesome-react-hooksとかawesome-reduxとか思いつくのはだいたいあるキガス

**デフォルトの名無しさん** · 2021/09/27(月) 11:55:16.25

JSだとホットリロードが機能するけどTSだと機能しないのだけど
これはTSの自動トランスパイルが機能してないってことですかね？

**デフォルトの名無しさん** · 2021/09/27(月) 11:57:06.64

>>170
？

**デフォルトの名無しさん** · 2021/09/27(月) 12:09:11.49

再起動したら直ったわ

**デフォルトの名無しさん** · 2021/09/28(火) 17:29:52.40

reactのコンポーネントにクリックとかのイベント処理を付ける時って、onClick＝｛clickHandler｝みたいに書くじゃない
このclickHandlerの処理の中でコンポーネントに渡してある属性を参照したいときってどう書くんだ？

clickHandlerを関数を返す関数にして、

clickHandler ＝（props）＝＞ () ＝＞｛‥｝

コンポーネントにはonClick＝｛clickHandler(props)｝ってやればできるんだけど、これだとuseCallbackが使えなくて毎回レンダリングし直されちゃうんだよな
event.targetはネイティブのDOMの情報しか載ってこないし、誰か教えてえろいひと

**デフォルトの名無しさん** · 2021/09/28(火) 18:22:37.60

>>173
JSの基本機能にクロージャーというのがあってだな
なんと！clickHandlerの中から外(つまりコンポーネント)の変数を参照できるんだよ！

const clickHandler = () => {
console.log(props.xxx)
}

useCallback使ってるならdepsに並べる

const clickHandler = useCallback(() => {
console.log(props.xxx)
}, [props.xxx])

**デフォルトの名無しさん** · 2021/09/28(火) 21:49:04.22

>>174
変数名をpropsにしたのが紛らわしかったかもしれんが

｛arr.map((v)＝＞｛
　　＜ComponentA　key＝v.Id　onClick＝｛clickHandler｝ /＞
｝)｝

みたいなことをやってるときにclickHandlerの処理の中でvを参照するにはどうしたらいいのかな？っていうのが聞きたいことなんだが、クロージャ？にあたるのか？
分かりにくくてスマン

**デフォルトの名無しさん** · 2021/09/28(火) 22:23:47.81

memo 化したコンポーネントで ComponentA をラップし props と clickHandler を受け取って onClick=｛() => clickHandler(props)} とする

**デフォルトの名無しさん** · 2021/09/28(火) 22:25:37.88

>>175
それならComponentAにvを渡してその中で

onXxx={(ev) => clickHandler(ev, v)}

**デフォルトの名無しさん** · 2021/09/28(火) 23:04:47.64

>>176
なーるほどなぁ、面倒だけど確かにそれならできそう

>>177
おー？これはuseCallbackで包めるんか？ちょっと明日試してみるわ

おまえらthx

**デフォルトの名無しさん** · 2021/09/28(火) 23:30:14.37

>>178
input等のdomにマップされるコンポーネントに直接渡す関数をuseCallbackする必要はない

**デフォルトの名無しさん** · 2021/09/29(水) 23:01:40.05

>>177
あ、これ>>176と同じこと言ってるんか、勘違いしてたわ
このためにラップしたコンポーネントを作らなきゃいけないってのはなんかイマイチだけどそれくらいしかなさそうね。ありがとう

**デフォルトの名無しさん** · 2021/09/29(水) 23:13:02.36

>>180
え？177は俺だけどラップしたコンポーネントってなんのことかわからねーぞw
ComponentAもおまえが作ってるんならそんなのいらないだろ

**デフォルトの名無しさん** · 2021/09/30(木) 12:42:41.23

componentAが自作かそうでないかに関わらず言ってることは同じだわな
どちらも子コンポーネント内で実装しないといけないことを言ってるんだから

**デフォルトの名無しさん** · 2021/09/30(木) 14:23:21.02

質問主はどう見ても>>155なんだから自作前提でよくて余計なことは省いた方がいいと思うね

**デフォルトの名無しさん** · 2021/10/03(日) 21:36:14.94

material-uiのspeed dialをネストしたいんだけど無理かな？speed dial actionの代わりにspeed dialそのものを子に持ちたい

**デフォルトの名無しさん** · 2021/10/19(火) 10:58:01.20

VSCodeでsassファイル保存時に自動フォーマット掛けたいですけどそれ出来る拡張ありますか？

**デフォルトの名無しさん** · 2021/10/20(水) 21:47:12.22

>>185
marketplace.visualstudio.com/items?itemName=BdSoftware.format-on-auto-save
標準搭載してほしいわ

**デフォルトの名無しさん** · 2021/11/09(火) 10:45:02.06

イベントと副作用フックどっちでもいい時に、どちらを優先して使うほうがより良いとかってある？

keyを入力するテキスト入力欄、valueを表示するテキスト表示欄がある
keyが変化するとデータを鯖から取ってきてvalueに設定したい

副作用フックでkeyを監視するか、key入力欄の変更通知イベントを使うか、どっちでもいいけど、どちらかというとどっちが良いか？

**デフォルトの名無しさん** · 2021/11/09(火) 11:13:14.15

入力欄の変更イベントで十分だろ
そしてuseDefferedValue経由の値でサーバを叩く

**デフォルトの名無しさん** · 2021/11/17(水) 09:45:52.91

素朴な疑問
状態を持ったり副作用を持ったりするコンポーネントってぶっちゃけclassのほうが可読性いいよね？
フックは書く時は楽だけど後で見るとナンジャコラ？ってなる

**デフォルトの名無しさん** · 2021/11/17(水) 10:40:45.63

>>110を読んでないってわかんだよね

**デフォルトの名無しさん** · 2021/11/17(水) 11:55:31.75

例えばの話、コンポーネントの初期化処理と終了処理はどこでやるの？って新人の疑問に対して

classコンポーネントなら
見たまんまcomponentDidMount、componentWillUnmountだよ
このメソッドを用意しとくとこのコンポーネントを持って管理してるフレームワークさんが、
いい感じのタイミングで呼び出してくれるよ
こう教えてやれば、直感ですぐさまなるほど、と理解して貰える

しかし関数コンポーネントでは純粋関数とは何か、副作用とは何か、フックとは何か、useEffectとは何か、useEffectの引数は何か、引数の戻りの関数は何か
ということをよく理解して頭の中で読み替えないといけない
なのでじっくり時間をかけて教えても、それでも理解するには時間を要する

関数コンポーネントはこんなのが無数にある
だから理解しにくい
タイピングの文字数は減るので書くのは楽だ、ということは確かだが
理解しやすさで言うと、ちょっとね、、、

**デフォルトの名無しさん** · 2021/11/17(水) 16:48:12.54

宣言的なReactを命令的に読み替えるんじゃ永遠に理解できないだろうな
そういう教え方をされる新人がかわいそうだし同情しかない

**デフォルトの名無しさん** · 2021/11/17(水) 20:00:29.63

reactでいくつかのファイルがあって保存(ctrl+s)すると
コンパイルしてくれるファイルとしてくれないファイルがあるんだけど違いってなんですか。。。

**デフォルトの名無しさん** · 2021/11/17(水) 20:55:02.32

使ってるide (vscodeとか) のスレで聞け

**デフォルトの名無しさん** · 2021/11/17(水) 21:47:40.34

>>191
クラスって何？メソッドって何？継承って何？

**デフォルトの名無しさん** · 2021/11/17(水) 22:25:06.52

>>191
クラスだとマウント／アンマウントじゃなくてpropsが変わるたびに開始処理終了処理するってなると全然違うこと教えなきゃダメだろ

**デフォルトの名無しさん** · 2021/11/18(木) 00:22:44.81

レアクトは宣言的だけど実用的なアプリケーションは全て有状態の手続きの塊じゃん？
ということはレアクトと「この不都合な現実世界」を上手いこと切り離して管理する方法が必要なんだよ
それがオブジェクト指向ってわけでね
関数コンポーネントは分離すべき手続きと宣言が渾然一体となっていてわかりにくい
オブジェクト指向を使えば
オブジェクトとオブジェクトを描画する純粋関数に分離することは容易い
それがrenderメソッドな訳だな

**デフォルトの名無しさん** · 2021/11/18(木) 00:44:06.97

レアクト

**デフォルトの名無しさん** · 2021/11/18(木) 00:47:56.13

また知恵遅れクラス信者か
この流れ何度目だよw

**デフォルトの名無しさん** · 2021/11/18(木) 01:15:46.87

関数が優位に立つのはDOMのレンダリングだけ
状態管理と手続きという不可避の現実はオブジェクト指向で処理したほうがいい
関数は状態が無いものだけを扱うべき

**デフォルトの名無しさん** · 2021/11/18(木) 07:26:11.67

状態や手続きを分離する方法はオブジェクトだけじゃない
モナドもそれだしReactの場合は代数的作用が背景にある

**デフォルトの名無しさん** · 2021/11/18(木) 07:56:21.14

>>70辺りからの話を繰り返してるな
高々200しかレスがない過疎スレなんだから一通り読んでから書けばいいのに

**デフォルトの名無しさん** · 2021/11/18(木) 08:07:20.27

>>201
できる、と、簡単にできる、は全く違うからなぁ
モナドもあるしとか言っても、それはオブジェクト指向の簡単さ、理解しやすさ、使いやすさには到底及ばないわけだよ

**デフォルトの名無しさん** · 2021/11/18(木) 08:56:13.25

それってオブジェクト指向を学んでから進歩してませんって自己紹介にすぎなくてオブジェクト指向がしっくりこなかったstaticおじさんと同じなんだよな

**デフォルトの名無しさん** · 2021/11/18(木) 10:18:03.07

理解しやすさ簡単さはオブジェクト指向から学んできたおじさんと関数型から学んできた若者で違うから議論してもしゃーない
それよりReact18がベータになったことだしConcurrent Renderingを知るべき
そしたら行儀の悪いクラスコンポーネントがReactにとって不都合だとわかるし関数コンポーネントで行儀の悪いコードを書きにくくしてることもわかるだろう

**デフォルトの名無しさん** · 2021/11/18(木) 10:23:00.26

Concurrent Renderingでは1回のレンダリングでrenderメソッドや関数コンポーネントが複数回呼ばれることが起こるようになる
いわゆる再レンダリングで複数回じゃなくて例えばdidMountが呼ばれる前にrenderが何度も呼ばれることが起きるようになる
だからrenderメソッドの中でthis.xxxを更新するなどの副作用があると破綻する
それは元々やるべきことじゃなくて行儀か悪いだけなんだがクラスコンポーネントでは書こうと思えば簡単に書けてしまう
そういうバグを検出するために前から用意されてたのがStrictモードだがあまり使われてるのを見たことはないな
クラスコンポーネントだとthis.stateはthis.setStatateを通じてReactが管理してるがその他はクラスコンポーネント任せで野放しになってるのがReact側から見た問題
そこで導入されたのが関数コンポーネントで状態や副作用の扱いが制限されて簡単に見えないのは意図的なんだよね

**デフォルトの名無しさん** · 2021/11/18(木) 10:29:08.68

将来のReactではマウント・アンマウントも複数回行われるようになる
これもコンポーネントのインスタンスが変わる場合の話じゃなくて一つのコンポーネントインスタンスが何度もマウント・アンマウントを繰り返すようになる
クラスコンポーネントではdidMount/willUnmountか同じthisの上で何度も呼ばれることになるんだろう
だから従来のライフサイクルという考え方だと破綻する
useEffectは以前からライフサイクルと考えてはいけないと言われてるしそのためにuseEffectのコールバックは冪等にすべきという原則もある
React18ではそれによって起きる問題を検出するためにStrict Effectモードが増える
こうなるとuseEffectを従来の初期化処理・終了処理に読み替えて理解させるのは単純に間違いということになる
どちらが理解しやすいかという次元の話じゃないんだよね

**デフォルトの名無しさん** · 2021/11/18(木) 13:11:55.12

それはuseStateを使うかlet変数宣言を使うかってのと同じこと
行儀の悪いコードはファンクショナルでも好きなだけ書ける
ようするにプログラマの腕とモラルの問題
ファンクショナルがクラスに対して優位と示す証拠ではないな

Reactが将来のバージョンアップでライフタイムサイクルの仕様変更となるなら
新しいライフタイムサイクルに適応したライフタイムサイクルメソッドを設ければいいだけ
そしてその方がuseEffectより遥かに直感的で理解しやすくなるだろう
実際どんな名称になるかはレアクトマニアでない俺は知らんがおそらくは
initializeComponent
componentDidMount
componentWillUnmount
disposeComponent
この辺りだろう
なんてわかりやすいんだ！

そもそも仕様変更されるからファンクショナルのほうがいいんだーって論理破綻しとるよな
仕様変更されたらそれに合わせてクラスコンポーネントも進化するのが当たり前
進化しないならそれはベンダーの怠慢

**デフォルトの名無しさん** · 2021/11/18(木) 14:18:18.92

ライフサイクルが変わってもuseEffectは影響を受けない
なぜならライフサイクルを扱う機能ではないから
ライフサイクルという考え方そのものを改めたのが今の関数コンポーネントとhookなんだよ
だからライフサイクルメソッドを増やせばいいなんて話ではないんだが伝わらないんだろうなw
まぁ、取り残されたければそれでいいんじゃない？
ここで吠えてもReactチームがクラスコンポーネントを進化させることはないよ
本気で主張したけりゃここに行きな
https://github.com/reactwg/react-18/discussions