React と React Native のスレ
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. 両方です。どっちの話題をしているかは文脈で判断してください >>1
React と React Nativeをソースレベルで共通化する試み
React Native for Web (★12,764)
https://github.com/necolas/react-native-web
React Native DOM (★3,025)
https://github.com/vincentriemer/react-native-dom 以前ちょっと触ってみただけだけど
ReactNativeってimportしたエレメントじゃなきゃhtmlタグとかは使えんのよな そんなんやりたいならガワだけネイティブのいわゆるハイブリッドフレームワーク使ってその中でreact使えば?react nativeじゃなく。
なんでそんなことしたいのか知らないけど。 去年の秋頃だったか流行ってるみたいだったから試してみだたけ
別に本格的にアプリ作ろうなんて気はなかったしReactと同じように掛けるのかなと思ったけど認識違いだったってだけの話だよ ReactでCanvas使う場合ってcomponentDidMountでcanvas.getContext("2d")ってやるの正しい?
それとも持っとReact的にもっとスマートなやり方とかある? React Native公式ブログ
https://facebook.github.io/react-native/blog/2019/03/12/releasing-react-native-059
・ver 0.59
・フックが使えるようになった
・JavaScriptCore強化: Androidで性能向上、64bitサポート
・起動高速化のためのJSモジュールの遅延ロード機能
(他省略) JSXで書いたファイルを、
HTMLとJSに変換する方法があれば教えて頂けないでしょうか・・・。 >>12
前提知識が不明なのでとりあえず順番に
1. 「node.js インストール」でググる
2. 「npm react インストール」でググる
3. 「webpack react ビルド」でググる
概要としては node上で動くnpmコマンドで
React, webpack, Babelをインストールして、webpackでビルド
それとJSXはJavaScriptの構文拡張でしかないから
変換(ビルド)で出てくるのはJSだけ >>13
失礼しました・・・。
node.jsはすでに入れてあり、reactはcreate-react-appからのを使っています。
webpackとbabelはreactを使う上でよく聞きました(ほとんど使えませんが・・・)
>それとJSXはJavaScriptの構文拡張でしかないから
>変換(ビルド)で出てくるのはJSだけ
というのは、>>13さんのwebpackでビルドしてもhtmlは出ない(jsファイルのみ出来る)という事でしょうか? >>14
npm run build
でdistフォルダに生成されてない?
package.jsonにscriptsって項目で
npm run 〇〇
で使えるコマンド一覧が書いてあるから一度確認してみ >>14
create-react-appなら npm run build でビルド出来る (裏でwebpackやbabelが動く)
js(JSX)をビルドするだけならhtmlは出ない
create-react-appならhtmlの最適化コピーを出すようになってる
元ファイルは public/index.html にあるはず >>15
>>16
ありがとうございます
そういうことだったのですね・・・
無事出力されました。
buildしたファイルにindex.htmlができました。
改行がされず最小の表示?(min.jsの様な)になっているのですが、
こちらをj従来の読みやすさ重視で表示できる様にする方法はありませんか…?
reactで作っている傍、知人にはhtmlとjsで同じ構成のを見せたくて、
reactで書いたのに別途htmlとjsで同じものを作るのも大変なので、そういった方法があればなと。 Babel
https://babeljs.io/docs/en/babel-preset-react
@ babel / preset-react
このプリセットには常に、次のプラグインが含まれています。
@ babel / plugin-transform-react-jsx など! >>17
npm run eject
node_modulesのreact-scriptsをプロジェクトルートに移してから
react-scriptsの中身を書き換えてビルドプラグインとかを抜けばいいけど
詳しいやり方はQiita漁ったら確かあったと思うから探してみ >>17
ReactはJavaScriptで動的にページを構築するからhtmlファイル自体は殆ど空っぽだよ npm run eject やった後にできた
scripts/build.jsの
const config = configFactory('production');
↓
const config = configFactory('development');
と
config/webpack.config.jsの148行辺り
path: isEnvProduction ? paths.appBuild : undefined,
↓
path: isEnvProduction ? paths.appBuild : paths.appBuild,
に書き換えたら良さそうだね
minify掛かってなくてもやっぱ見づらいけど とりあえずなんか見せるためだけなら、最終的にブラウザで表示されてる html だけとってこれば?ページ表示してブラウザの保存機能でここまでならできる。 js は react じゃない部分だけ取り出すのはむずいと思う。自分で書き直してあげるしかない。 そういやReactでClassコンポーネント作るとき
extends React.Componentって書くけど
自作クラスを中間クラスとして中継して継承するのってあんまやらないもんなの? 継承はせずに単なるコンポジットかHigher Order Componentsでやってる classコンポーネントはほぼ使わないな
前はrecompose使ってたし今はhooksあるし ほんとクラスのキッタネエ構文大嫌いだわ
そもそも生まれてこなきゃ良かったのにオブジェクト指向つってもクラスベースじゃないっつーの
es2015でねじ込んだヤツ呪われろ React + Redux を使用したモダンフロントエンド開発
https://www.udemy.com/react-redux-basic/
これを1200円で購入したよって人いる・・・?
Udemyはしょっちゅう1200円セールしてるけど、これも1200円になったりするかな
現状の9600円となるとお財布が厳しくて・・・ React Native 公式blog 2019/06/12
https://facebook.github.io/react-native/blog/2019/06/12/react-native-open-source-update
React Native 0.60, TurboModule, Lean Core, アップグレードコマンドの改善などの話 React Nativeの改善に関するサブプロジェクトあるいは用語
Lean Core: リポジトリの再編成(コンポーネントの分離)
TurboModules: NativeModulesの新構造(JSIを使用した改善)
Fabric: UIレイヤの新構造(JSIを使用した改善)
JSI: JavaScript Interface, JS-Native間のブリッジを高性能化する仕組み オレオレミドルウェア
suspenseが来たらreduxもろとも捨てる React+Reduxやってるけど、MとVM的なものが分離されないのがつらくなってきた。
他のfluxフレームワークだとどうなんだろう。 所詮プレゼンテーションレイヤーのフロントエンドにMを持ち込むタコは何を使っても同じ >プレゼンテーションレイヤーのフロントエンドにMを持ち込む
なにかマウントとりたい意思は伝わってくるけどさすがに意味不明。 MVCとかMVVMとかって小さい単位での独立部品の切り出しを考えたら結構邪魔なんだよね 久々に動かしたらmetro bundlerなるものができてた
ナンジャコリャ ・Hooksのフォローアップの作業量を過小評価していた
・Concurrent Mode と Suspense for Data Fetching の作業に注力
Facebookのサイトで実際に試していてリリースに向けて修正中
この辺で時間掛かっているらしい create-react-app xxx とすると、
xxxというreactアプリ(フォルダ)が作られますが、
このxxxの部分を変更したい場合、そのままフォルダを編集してしまっても問題ありませんか?
他にもpackage.jsonのnameもxxxになっておりますがこちらも変更したりして React Native 0.61
https://facebook.github.io/react-native/blog/2019/09/18/version-0.61
・ライブリロードとホットリロードは新実装のファストリフレッシュに統合された
・0.60で支障があったCocoaPodsでのuse_frameworksの問題が解消 ReactNativeでaxios動かないんだが。。。 vscode+react+material-ui使ってるんだけど下のコードでボタンが赤にならないのなんでだろう・・・
なんかPrimaryが紫になってるんだが・・・
import { createMuiTheme } from '@material-ui/core/styles';
import red from '@material-ui/core/colors/purple';
const mytheme = createMuiTheme({
palette: {
primary: red,
},
});
const useStyles = makeStyles({
button: {
backgroundColor: mytheme.palette.primary.main,
},
});
export default function CenteredGrid() {
const classes = useStyles();
return (
<div className={classes.root}>
<Grid container spacing={0} justify={'center'}>
<Grid item xs={12}>
<Button className={classes.button} variant='outlined'>
botton
</Button>
</Grid>
</Grid>
</div>
);
} ごめん自決して
カラーのimportミスってた
×import red from '@material-ui/core/colors/purple';
◯ import red from '@material-ui/core/colors/red';
スレ汚しすまん 初歩的な質問で申し訳ないのですが
リセットCSSを適用させようとすると、スタイルがリセットCSSのみしか適応されません。
具体的には・・・
App.js
import React from "react";
import { render } from "react-dom";
import "./reset.css";
import "./first.scss";
import { BrowserRouter, Switch, Route } from "react-router-dom";
こんな感じのをApp.jsに読み込ませているのですが、
reset.cssをインポートするとreset.cssのHTMLがリセットされたスタイルしか反映されず、first.scssは反映されません。
reset.cssを外しfirst.scssのみにすればちゃんとfirst.scssの内容がHTMLに反映されます。
HTMLのCSSをリセットしてから、オリジナル(first.scss)に変更といった事がしたいのですが、
どうすれば良いでしょうか?
reset.cssはこちらのHTML5 Doctor Reset CSSというのをreset.cssにコピペしてインポートしています。
http://html5doctor.com/html-5-reset-stylesheet/
試しにfirst.scssの中身の最上部にHTML5 Doctor Reset CSSの中身を張り付けてみたのですが同じでした。 importされるのはcssじゃなくてjs(実質reset.css.js)だからね
問題はwebpackの設定じゃないの?
webpack entryでググってみたら? 最近androidシミュでfetchが上手くいかなくなったけど何でだろ? >>54
システム全体で必要なのはRedux
Postする為にそのFormだけで必要なものはuseState
って使い方してる
共存って点で言うならHooksか旧型式かを共存させなきゃ別にいいと思う React.ComponentとSuspenseを使ってリストを読み込んで表示するプログラムを書いているのだけど
renderでメンバ関数を呼んで読込するとthisがつく変数(stateとか)が全てリセットされるよどうして?
リセットされる変数をstaticにすると動くようです 人工知能フレームワークのGpt-3がReact上で動くんだよなあ >>56
まだそんな事やってるのか?
早くHooksに移行した方がシンプルで使いやすいよ reactでフォームの連動させたいんだけど
良いチュートリアルやサンプルをおしえてください
調べ方でも大丈夫です >>59
公式を嫁!
それか、オレの知り合いの本を嫁!
以上。 他のフォーム要素を同時にどうかしたいって仮定するとonClickイベントやonChangeイベントのコールバックにメソッド噛ませればいいんじゃない? Html,Javascriptのソースコードをreact nativeに書き直してるけどDom要素のID管理していたのを書き直すのが辛すぎる
何かよいライブラリないかなぁ iOSやAndroidアプリを作りたくてprogateのhtmlとJavaScriptと reactまでやったんですが、次に何をすれば良いか分かりません。僕は次に何を学べばいいですか? (u_・y)順序からしておかしくね
(u_・y)Androidアプリ作るならまずAndroid上でハローワールドだろ
(u_・y)Googleになんかアカウント作って登録あれこれやるんじゃねーの
(u_・y)Win以外のアプリを作るので難関になるのはそういった手順と環境構築絡みなので、
(u_・y)周りに先生がいない状況で独学初心者がいきなりAndroidアプリってのはハローワールドまでに時間かかるぞ Java から来て、最近 React はじめたんだけど、MVC 思想的なのは最近フロントエンドではなくなっていってる感じなん?
せめて View 部分は分けないと気持ち悪いんだけど、チュートリアルみても割とごちゃまぜなのよね… React の hookを初めてみてるんだけど、
これClassベースの機能で提供できないのかな?
functionなのに永続化を無理やりやってるようでコード読みづらい。
その永続化をuse接頭語のみで判断しなければならないという...
functionじゃなきゃhookの機能が提供できない??というモヤモヤ感が払拭できないです。 元々はクラスベースで提供されてた機能を関数コンポーネントでも使えるようにしたのがhookやで >>68
目に見える副作用をフレームワーク側に追い出して
ユーザーからは副作用がないようにしてる設計は素晴らしいと思うけどね >>70 副作用がないようにしてる設計
それがclassベースでは出来ない??って疑問。
>>69
ならhookがclassより上という事ではなくなる。
でも公式コメントでもclassよりhookのモデルが優秀みたいな書き方。
ただclassは無くさずこのまま残しますみたいな。
なんかfunctionを無理やり生存期間拡張してるところが
感覚的に違和感モヤモヤ。
hookの機能をclassで実装するとやりづらい箇所って、
同名メソッドを複数定義できる箇所ぐらい? >>71
もちろんできるしそれを手動でやってきたのがクラス
でもsetState呼ばなかったり状態にオブジェクトが必須だったりで色んなミスが起きやすかった
それをフレームワーク側で全部やって
ユーザーが書きやすくするのがHooks
人間がやるよりフレームワークがやる方が信頼性が高いし賢いからそこは任せた方が良いよねってことで生まれたと勝手に思っている >>72
だから、それ(hook)をclassべースで提供できないの?って言ってんの。 クラスはhookなしで同じことができるから提供する必要がない >>73
いやだからsetStateという汎用的な物しか提供できないっことね
stateを自分で好き勝手いじれるのに
それをライブラリが管理するって無理でしょ
hooksは内部で対応するコンポーネントとその状態を管理してるから
ライブラリとして提供できる >>75
分かんない人だな。
なんで今のclassベースの実装をこの話に持ち込むの。
hookの機能を”function”でなく、jsの”class”で実現できないの?っていう疑問なの。 お前もわからずやだな
useStateだろうがuseEffectだろうがuseCallbackだろうがuseRefだろうがclassコンポーネントはhookなしで同じことが実現できてるだろ 時系列的には
クラスコンポーネント: 状態を扱える
↓
"ステートレス"関数コンポーネント: 状態を扱えない
↓
関数コンポーネント+hooks: 状態を扱える
と発展してきた
つまりhooksはクラスコンポーネントができていたことを関数コンポーネントでもできるようにするために後から追加されたもの
ただし
クラスコンポーネント: 状態をコンポーネントが管理する
関数コンポーネント+hooks: 状態をフレームワークが管理する
という違いがある
これが今後のconcurrent modeやserver componentsで大きな違いになってくる
フレームワークができることを増やすにはコンポーネント側の自由度は低い方がよくてそれがpureな関数コンポーネント >>79
この解説から見ると、自分の疑問は
"状態をフレームワークが管理する"
にはclass実装では不利なのか?向かないのか?
って事になる。ね。 クラスコンポーネントのインスタンスはthis.〜で自由に状態を扱えてしまうからフレームワークには都合が悪い
そこをthis禁止のように縛っていくとただの関数でいいやってなる useCallbackみたいな単なるラッパー関数がclassにも欲しいってこと?
なんかそう言うパッケージ見たことあるぞ classコンポーネントにuseCallbackはいらんやろ
前はbindしたり面倒だったけどstage3のclass fields使えばこれだけ
class Foo extends React.Component {
handleClick = (ev) => {...} Ruby on Rails では、控えめなJS フレームワークのStimulu もある
規約で、HTML のdata-controller 属性で、JSファイル名・コントローラーが決まるので、
そこにイベント処理を書くだけ
DOM・コントローラーは、多対多
1つのDOMは、複数のコントローラーで処理できる。
HTML内で、同じコントローラーを複数定義できる
Stimuluは、this を使う。
同じコントローラーを複数定義したら、別のインスタンスを作る
<li data-controller="a">1</li>
<li data-controller="a">2</li> マジで障害者かな?
この板に巣食ってる人がいるのは認識してたけど React Hooks + Reduxの利点を述べた記事をいくつか読んだのですが、
MVCでだめな理由がよくわかりませんでした。
複数のModelがReduxのStoreに一本化される: Modelをシングルトンにして、
Storeの内部で区分するところをModelのメンバとして区分する。
ViewからはActionを発行してReducerを通さないとStoreを更新できない:
ViewはControllerに登録されたメソッドを通してしかModelを更新できない。
Storeの更新はViewに自動的に反映される。
Model(とそのメンバ、孫メンバ)がObservableであれば、Modelの更新を
自動的にViewに反映させることができる。
ではだめなんでしょうか。 Reactで関数コンポーネントで本気実装始めたんだが、
関数コンポーネント面倒くさ過ぎじゃね?
関数コンポネント入門位の実装なら問題なかったんだが、
ちょっと込み入ったの実装しようと思ったら
クラスじゃないんで、コンポーネントの自前メソッドを(子から親、親から子)公開するのとか
そのTS型定義をどうするのとかうまく解決できんのか?これwww 込み入った実装ってだいたい設計から間違ってるよね… >>89
あんたが考えてんの具体的にどのレベルだ?
こっちはネイティブアプリ同等の、ガントチャート状のスケジューラーの実装なんだが
コンポーネント間のメソッド呼び出しは結構多いぞ 奇遇だな、Webとネイティブ両用のスケジュール管理系やってるよ
推測だけどコンポーネントとデータ構造(いわゆるモデル)が分離できてないんだろうと思うわ
同じものをネイティブでも作ることを仮定して共有できるところ(モデル)とできないところ(レンダリング)にわけて考えてみるといんじゃね >>91
!!
まだReact不慣れで困ってる
半年前にReact初めてそちはクラスベース(TS)だったので、
実装できない事は無かったのでこういった苦労はなかった
>>コンポーネントとデータ構造(いわゆるモデル)が分離できてないんだろうと思うわ
どうだろう?
あんまり業務的なことを書くわけにはいかんけど、
親パネル側から、配置されたコンポーネントの機能を呼び出したいんだが、
コンポーネントが今回クラスから関数に変わったんで、
コンポーネント側にコンポーネント固有の機能(クラスん時はメソッド)が実装しずらくなって困ってる
関数コンポーネントだとここにメソッドとか置かないもんなの? 関数なんだから、オブジェクト指向的な実装はムリなんだろうな
とりあえず、
・クラス → モジュール
・プロパティ → モジュールの関数の引数
・メソッド → モジュールの関数
に置き換えて実装してみるわ 関数であれクラスであれ(つかもっと前から)Reactのコンポーネントは渡されたデータ(Props)をただベタッとレンダリングするだけってのがコンセプト
その超基本的なところをわかってなさそう
他の言語やフレームーワークの考え方のままReact始めたのか知らんけどそれをReactに置き換えるよりReact流の考え方を身につけたほうがいいと思うわ いや、アトミックデザイン的に機能分割して
その単位をオブジェクト指向的にデザインしてたわー−(前回プロジェクト)
でもRender()しかやらん関数と、
その外にはみ出た処理で細切れ関数だらけになって、
コード読みにくいは、実装も美しくならんわー− ( ノД`)ドスル Redux素晴らしいって言ってた人たちは今息してんのかな >>95
この流れでアトミックデザインを出してくるのものすっごく薄っぺらい >>97
アトミックデザイン使わず
あなたが表現してあげたら? >>98
単純にいらんやろ
「コンポーネントをオブジェクト指向でデザインしてた」で十分だしそれがReactらしくないって話やん >>100
この流れで分割単位の話なんかいらないじゃん
88から読み直してみ > コンポーネント間のメソッド呼び出し
?????????? データフェッチに swr を使う前提であれば Recoil より swr で状態管理 hooks 作る方が良いんだろうか
両方使う例があるなら見てみたい >>103
swrはサーバーサイドの情報を取ってきてキャッシュするものだから扱う状態はサーバーステートとでも呼ぶべきものなんだよね
だからクライアントサイド固有の状態を
swrで扱おうとは俺は思わない
apolloなんかはクライアントのステートも一緒に扱えるのを売りにしてるけど余計な手間をかけてるだけにしか見えない
コンポーネントのローカルステート→useState, useReducer
クライアントのグローバルステート→redux, recoilなど(俺は好かんがcontextもここに入る)
サーバーステート→swr, react query, apolloなど
と使い分けてる >>104
参考になるありがとう
依存ライブラリ増加を嫌うことへの妥協案で >>103 を考えてたけどその方が役割分担が明確だから状態と取得キャッシュが混合するより状態を把握しやすそう >>106
ぶっちゃけクラスの方が書きやすく
コードも綺麗だ(実力高い人の場合)
関数コンポーネントは
実装の自由度がhocksbニその拡張ぐらb「しかなく
フレームワーク的なのが造りづらく感じてる 実力が高いw
本気でそう思ってるならqiitaでもzennでもどこでもいいから記事に書いてみろよ
間違いなく日本中からボロクソに叩かれるよ >>107
クラス記法はこういう欠点があるからなあ
ttps://speakerdeck.com/sonatard/coheision-coupling?slide=24 大方の単細胞腦は、SQLDBとNoSQLDBの時がそうであったように
関数コンポーネントとクラスコンポーネントのどちらかに
絶対的な優劣をつけたがってんじゃね?
今回も関数コンポーネントがマッチする場合と、
そうでない場合がありそうに見える
とくに、関数コンポーネントは
コンポーネントのインスタンスが自由に扱えない(扱えなさそう)から
そういった処理の実装時に(React用で無いJSライブラリを無理やり動かしてたようなケースとか)
トラブりそうな気がする 優劣はどうでもよくてクラスコンポーネントは互換性のために残されてるだけってのがReactの立場
新しい機能の中には関数コンポーネントからしか使えないものが出てるしこれからも増える
そもそも対等な選択肢ではないから議論する価値がない
状況に合わせて適応するってのが一番大事 >>113
>> 互換性のために残されてるだけってのがReactの立場
なんと!(; ・`д・´) 今の公式ドキュメントやチュートリアルは古くてクラスコンポーネントが大きく扱われてるのが本当に良くない
それはReactチームも分かってるからドキュメントを全面的に書き換えてる最中
もちろん関数コンポーネントとHooksメインで フック初心者ですが
「フックは関数のトップレベルのみで呼び出してください。」
とあります。この関数は関数コンポーネントの意味で合ってますでしょうか? <Button1>と<Button2>で
それぞれ内部でuseStateを使ってたら
<Button1>
<Button2/>
</Button1>
はNGになるのでしょうか? >>117
> この関数は関数コンポーネントの意味
違う
ifやforなどの制御構造の内側から呼び出すなということ
要するに関数コンポーネントの呼び出しごとにhookが実行されたりされなかったりしてはいけない
なので?:や&&などと組み合わせるのもダメ >>118
それはOK
それぞれのコンポーネントは独立してるから問題ない >>120
有り難い!
しかし判り辛いですね
お題目だけだと
公式に具体例を上げてくれないと
勘違いしそう... hookの実行順でレンダリング毎の同一性を保証してるってわかってれば当たり前のことなんだけどね 順番で状態を管理してるって一昔前の考えだと
なんだそりゃって感じになるんだけど
そもそも自分で管理するのはクソだから
全部フレームワークに任せちゃえってなってる
React凄い 翻訳の問題かもしれんけど
「関数のトップレベル」という表現が判りずらい
「関数内部の最初の行あたり」で良くないか? function Foo(props) {
if (props.flag) useEffect(...)
...
最初の行だけどアウト 「同じフックが常に実行されるようにすること」
これでよくね? モジュールのトップレベルもわからない?
それじゃトップレベルawaitも分からないしJSやるの無理やろ useCallback これっている?
fnのMemoならMemoってキーワードも名称から抜けてるし
useMemo(() => fn, deps) と同じならなおさら... useCallback(fn, deps) が useMemo(() => fn, deps) こう書けるって事なんじゃないですか? useCallback((event) => {...}, deps) を useMemo(() => (event) => {...}, deps) って書きたいかって話 >>133
良い!
そっちのが良い!
fnのメモなのに、useMemoCallback()になってないので直観的に思えない
初学者だと、ぱっと見CallbackするにはuseCallback()が必須に見える
理由はMemoの文字が入ってないから それ言ったらuseMemoなんてuseState使えばいいし内部でstate使ってるのにuseNemoStateじゃないの直感的じゃないよね useCallback だと名称から、
コールバック使いますよ!の宣言に見えると言っている
実際はコールバックをメモしますよ!だから
コード読むとき直感的でないと言っている
実際、初学者で関数コンポネント内でコールバックを定義するときは
useCallback()を使わなければならないと思いこんでいる人が少なからず居ると思う Ionicと比べた場合のReact nativeのメリットはアプリの動作速度が速いところ? >>136
初学者は
> useCallback()を使わなければならないと思いこんでいる
で丁度いい >>140
不要なuseCallbackを書いても実害はない
超大規模ならチリツモでパフォーマンスに影響あるかもしれないが初学者には関係ない
対して必要なuseCallbackを忘れるとuseEffectやReact.memoに影響しうるが初学者には気付きにくい
最初は愚直にuseCallback書いて後から不要なケースを学べばいい >>141
なるほど!
その意味であえて関数名もそうしたんだろうか... カスタムフック===ユーザー定義フック
利用者(アプリケーション)で定義するものであってReactが提供する機能ではない >>144
それは了解してた!(質問を間違えた!)
フックを実現する技術(ステートレス関数に状態を保持する機能)は
JSに元からあるという記述が公式にあったようにおもうのだけれど、
それは何?って事が言いたかった... >>145
前のリンクの文意から推察するに、フックはreactの特別な機能じゃなく
JSのクロージャーと array.push と array.pop とかで実装できるって事かな?
誤りありましたらご指摘下さい >>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の内部実装について書いてあるとは考えにくいので何か勘違いしてるんだろう >>148
>>145 で言ったように、それは最初から解ってる
聞きたかったのは、フック自体の実装方法だよ!
>>149
そりゃそーーだ >>150
お前さぁ・・・
フック自体の実装方法が知りたいならそう書けよ
無関係なリンクや公式のことを書くから「そんなことは書いてない」「お前の勘違い」「ボケカス」って話になるんだよ
つーか5ch開く前にすることあるだろ >>150
preactのソースを読め
わずか400行そこらでhooksを実装してる
俺がここ数年で見たコードで最も美しいコードだ
型もついてるからめちゃくちゃ読みやすい
https://github.com/preactjs/preact/blob/master/hooks reduxでいままでやってたような処理ってhooksではuseContextとuseRuducerの組み合わせでやるってことであってます? 最近react始めて、リスト構造を持つようなデータの画面表示は配列のmap関数使ってjsx書けってのは理解したんだが、配列の要素の持つデータを一か所でも変えると残りの要素は全く変わってないのに全てレンダリング処理し直すことになるよな?
reactが差分を見てくれるから実際のDOMに反映されることはないんだろうけど、変更された要素のコンポーネントだけにレンダリング処理させる方法ってないんか? >>155
keyを使え
チュートリアルにも乗ってたはず >>155
要素を別コンポーネントにしてReact.memoする
その場合も156が書いてるようにkeyは必須
でも各要素のレンダリングがよほど重くない限り気にすることないと思うぞ >>156,157,158
dクス
もうちょい調べてみるわ >>159
リストの出力の場合
アイテム毎にkey必ず振らなければない
key無いのはバグだからね
コンソールにエラー出てるはず keyが必要なのは確かだがそれが影響するのはリアルDOMの更新
keyがないと
> reactが差分を見てくれるから実際のDOMに反映されることはないんだろうけど
が機能しなくなる
本来の質問であるコンポーネントのレンダリングを回避するのに必要なのはReact.memo ストアに登録する前に1ヶ月テスト運用したいのですがそんなこと可能なんですか?
テストユーザーは50名程度の予定です うーん、先に代弁してくれてる人もいる通り、自分が聞きたかったことを解消できるものじゃなかったな、keyを付けないかんてのは改めてよく分かったけど。memoに関しては配列でmap関数でjsx組立ててる場合に言及した解説サイトは見当たらんかったし、うまくいくかは一度書いて調べてみるかー >>165だけど、memo化して特定の子要素だけレンダリングが呼び出されるのを確認できたわ
ありがとう Vue.jsだと公式サイトからリンクにawesome-vueってのがあって
https://github.com/vuejs/awesome-vue
ここ(Components & Libraries)にVue向けのlibraryやcontrolのリストが列挙されてて大変便利なんですけど、
これのReact版とか無いですか? 言った直後にまんまのがあった...
awesome-react
awesome-react-components
笑 awesome-react-hooksとかawesome-reduxとか思いつくのはだいたいあるキガス JSだとホットリロードが機能するけどTSだと機能しないのだけど
これはTSの自動トランスパイルが機能してないってことですかね? reactのコンポーネントにクリックとかのイベント処理を付ける時って、onClick={clickHandler}みたいに書くじゃない
このclickHandlerの処理の中でコンポーネントに渡してある属性を参照したいときってどう書くんだ?
clickHandlerを関数を返す関数にして、
clickHandler =(props)=> () =>{‥}
コンポーネントにはonClick={clickHandler(props)}ってやればできるんだけど、これだとuseCallbackが使えなくて毎回レンダリングし直されちゃうんだよな
event.targetはネイティブのDOMの情報しか載ってこないし、誰か教えてえろいひと >>173
JSの基本機能にクロージャーというのがあってだな
なんと!clickHandlerの中から外(つまりコンポーネント)の変数を参照できるんだよ!
const clickHandler = () => {
console.log(props.xxx)
}
useCallback使ってるならdepsに並べる
const clickHandler = useCallback(() => {
console.log(props.xxx)
}, [props.xxx]) >>174
変数名をpropsにしたのが紛らわしかったかもしれんが
{arr.map((v)=>{
<ComponentA key=v.Id onClick={clickHandler} />
})}
みたいなことをやってるときにclickHandlerの処理の中でvを参照するにはどうしたらいいのかな?っていうのが聞きたいことなんだが、クロージャ?にあたるのか?
分かりにくくてスマン memo 化したコンポーネントで ComponentA をラップし props と clickHandler を受け取って onClick={() => clickHandler(props)} とする >>175
それならComponentAにvを渡してその中で
onXxx={(ev) => clickHandler(ev, v)} >>176
なーるほどなぁ、面倒だけど確かにそれならできそう
>>177
おー?これはuseCallbackで包めるんか?ちょっと明日試してみるわ
おまえらthx >>178
input等のdomにマップされるコンポーネントに直接渡す関数をuseCallbackする必要はない >>177
あ、これ>>176と同じこと言ってるんか、勘違いしてたわ
このためにラップしたコンポーネントを作らなきゃいけないってのはなんかイマイチだけどそれくらいしかなさそうね。ありがとう >>180
え?177は俺だけどラップしたコンポーネントってなんのことかわからねーぞw
ComponentAもおまえが作ってるんならそんなのいらないだろ componentAが自作かそうでないかに関わらず言ってることは同じだわな
どちらも子コンポーネント内で実装しないといけないことを言ってるんだから 質問主はどう見ても>>155なんだから自作前提でよくて余計なことは省いた方がいいと思うね material-uiのspeed dialをネストしたいんだけど無理かな?speed dial actionの代わりにspeed dialそのものを子に持ちたい VSCodeでsassファイル保存時に自動フォーマット掛けたいですけどそれ出来る拡張ありますか? >>185
marketplace.visualstudio.com/items?itemName=BdSoftware.format-on-auto-save
標準搭載してほしいわ イベントと副作用フックどっちでもいい時に、どちらを優先して使うほうがより良いとかってある?
keyを入力するテキスト入力欄、valueを表示するテキスト表示欄がある
keyが変化するとデータを鯖から取ってきてvalueに設定したい
副作用フックでkeyを監視するか、key入力欄の変更通知イベントを使うか、どっちでもいいけど、どちらかというとどっちが良いか? 入力欄の変更イベントで十分だろ
そしてuseDefferedValue経由の値でサーバを叩く 素朴な疑問
状態を持ったり副作用を持ったりするコンポーネントってぶっちゃけclassのほうが可読性いいよね?
フックは書く時は楽だけど後で見るとナンジャコラ?ってなる 例えばの話、コンポーネントの初期化処理と終了処理はどこでやるの?って新人の疑問に対して
classコンポーネントなら
見たまんまcomponentDidMount、componentWillUnmountだよ
このメソッドを用意しとくとこのコンポーネントを持って管理してるフレームワークさんが、
いい感じのタイミングで呼び出してくれるよ
こう教えてやれば、直感ですぐさまなるほど、と理解して貰える
しかし関数コンポーネントでは純粋関数とは何か、副作用とは何か、フックとは何か、useEffectとは何か、useEffectの引数は何か、引数の戻りの関数は何か
ということをよく理解して頭の中で読み替えないといけない
なのでじっくり時間をかけて教えても、それでも理解するには時間を要する
関数コンポーネントはこんなのが無数にある
だから理解しにくい
タイピングの文字数は減るので書くのは楽だ、ということは確かだが
理解しやすさで言うと、ちょっとね、、、 宣言的なReactを命令的に読み替えるんじゃ永遠に理解できないだろうな
そういう教え方をされる新人がかわいそうだし同情しかない reactでいくつかのファイルがあって保存(ctrl+s)すると
コンパイルしてくれるファイルとしてくれないファイルがあるんだけど違いってなんですか。。。 使ってるide (vscodeとか) のスレで聞け >>191
クラスって何?メソッドって何?継承って何? >>191
クラスだとマウント/アンマウントじゃなくてpropsが変わるたびに開始処理終了処理するってなると全然違うこと教えなきゃダメだろ レアクトは宣言的だけど実用的なアプリケーションは全て有状態の手続きの塊じゃん?
ということはレアクトと「この不都合な現実世界」を上手いこと切り離して管理する方法が必要なんだよ
それがオブジェクト指向ってわけでね
関数コンポーネントは分離すべき手続きと宣言が渾然一体となっていてわかりにくい
オブジェクト指向を使えば
オブジェクトとオブジェクトを描画する純粋関数に分離することは容易い
それがrenderメソッドな訳だな 関数が優位に立つのはDOMのレンダリングだけ
状態管理と手続きという不可避の現実はオブジェクト指向で処理したほうがいい
関数は状態が無いものだけを扱うべき 状態や手続きを分離する方法はオブジェクトだけじゃない
モナドもそれだしReactの場合は代数的作用が背景にある >>70辺りからの話を繰り返してるな
高々200しかレスがない過疎スレなんだから一通り読んでから書けばいいのに >>201
できる、と、簡単にできる、は全く違うからなぁ
モナドもあるしとか言っても、それはオブジェクト指向の簡単さ、理解しやすさ、使いやすさには到底及ばないわけだよ それってオブジェクト指向を学んでから進歩してませんって自己紹介にすぎなくてオブジェクト指向がしっくりこなかったstaticおじさんと同じなんだよな 理解しやすさ簡単さはオブジェクト指向から学んできたおじさんと関数型から学んできた若者で違うから議論してもしゃーない
それよりReact18がベータになったことだしConcurrent Renderingを知るべき
そしたら行儀の悪いクラスコンポーネントがReactにとって不都合だとわかるし関数コンポーネントで行儀の悪いコードを書きにくくしてることもわかるだろう Concurrent Renderingでは1回のレンダリングでrenderメソッドや関数コンポーネントが複数回呼ばれることが起こるようになる
いわゆる再レンダリングで複数回じゃなくて例えばdidMountが呼ばれる前にrenderが何度も呼ばれることが起きるようになる
だからrenderメソッドの中でthis.xxxを更新するなどの副作用があると破綻する
それは元々やるべきことじゃなくて行儀か悪いだけなんだがクラスコンポーネントでは書こうと思えば簡単に書けてしまう
そういうバグを検出するために前から用意されてたのがStrictモードだがあまり使われてるのを見たことはないな
クラスコンポーネントだとthis.stateはthis.setStatateを通じてReactが管理してるがその他はクラスコンポーネント任せで野放しになってるのがReact側から見た問題
そこで導入されたのが関数コンポーネントで状態や副作用の扱いが制限されて簡単に見えないのは意図的なんだよね 将来のReactではマウント・アンマウントも複数回行われるようになる
これもコンポーネントのインスタンスが変わる場合の話じゃなくて一つのコンポーネントインスタンスが何度もマウント・アンマウントを繰り返すようになる
クラスコンポーネントではdidMount/willUnmountか同じthisの上で何度も呼ばれることになるんだろう
だから従来のライフサイクルという考え方だと破綻する
useEffectは以前からライフサイクルと考えてはいけないと言われてるしそのためにuseEffectのコールバックは冪等にすべきという原則もある
React18ではそれによって起きる問題を検出するためにStrict Effectモードが増える
こうなるとuseEffectを従来の初期化処理・終了処理に読み替えて理解させるのは単純に間違いということになる
どちらが理解しやすいかという次元の話じゃないんだよね それはuseStateを使うかlet変数宣言を使うかってのと同じこと
行儀の悪いコードはファンクショナルでも好きなだけ書ける
ようするにプログラマの腕とモラルの問題
ファンクショナルがクラスに対して優位と示す証拠ではないな
Reactが将来のバージョンアップでライフタイムサイクルの仕様変更となるなら
新しいライフタイムサイクルに適応したライフタイムサイクルメソッドを設ければいいだけ
そしてその方がuseEffectより遥かに直感的で理解しやすくなるだろう
実際どんな名称になるかはレアクトマニアでない俺は知らんがおそらくは
initializeComponent
componentDidMount
componentWillUnmount
disposeComponent
この辺りだろう
なんてわかりやすいんだ!
そもそも仕様変更されるからファンクショナルのほうがいいんだーって論理破綻しとるよな
仕様変更されたらそれに合わせてクラスコンポーネントも進化するのが当たり前
進化しないならそれはベンダーの怠慢 ライフサイクルが変わってもuseEffectは影響を受けない
なぜならライフサイクルを扱う機能ではないから
ライフサイクルという考え方そのものを改めたのが今の関数コンポーネントとhookなんだよ
だからライフサイクルメソッドを増やせばいいなんて話ではないんだが伝わらないんだろうなw
まぁ、取り残されたければそれでいいんじゃない?
ここで吠えてもReactチームがクラスコンポーネントを進化させることはないよ
本気で主張したけりゃここに行きな
https://github.com/reactwg/react-18/discussions 本来ライフサイクルメソッドではないuseEffectを、ライフサイクル目的で使わざるを得ない、という状況が非常にバッドだよねぇ
APIの目的外利用ってバッドノウハウとか、黒魔術って呼ばれてるものだよ
最近はそういうの随分と減ったと思ったけど、ファンクショナルコンポーネントでは現役なんだなぁ
useEffectはライフサイクルじゃない!ってんなら
useInitializer
useFainalizer
この2つのフックはオフィシャルに提供した方がいいだろね
それをしないというのはベンダーの怠慢でしかないよ
そうすれば、useEffectの第二引数に謎の空配列を渡すと、お掃除する時にだけ呼ばれます!
なーんて回りくどい、明快さのかけらもない、暗黙の了解はもう、要らなくなるわけだ
冷静に考えてわかりにくいだろ? 空配列ってさ 本当に化石のような石頭だな
現場でもさぞかし迷惑な存在だろう
ライフサイクルって考え方をしないんだからuseInitializerもuseFainalizerも不要なんだよ
間違った理解
コンポーネントがマウントされたら一度だけxxを実行する
コンポーネントがアンマウントされたら一度だけyyを実行する
(やや)正しい理解
コンポーネントがマウントされてる間はzzの状態を維持する
zzの状態ってのはイベントをリッスンしてる状態とかwebsocketをサブスクイブしてる状態とか色々
useEffectのコールバックがそういう「状態を維持する」ものって考えると必然的に冪等にしなきゃいけなくなりConcurrent Renderingで繰り返し呼ばれても大丈夫になる
実際はマウントされてる間とかってのをもっと一般化して
正しい理解
依存配列が変わらない間は状態を維持する
と考える
空配列は変わりようがないから結果的にマウントしてる間はずっと状態を維持するってことになる
だからね、ライフサイクルって考え方がもはや不要で間違ってるんだよ
いつまでも古い考えに固執しないでちゃんと勉強して? >>211
で、それは手続きだらけの現実世界には対処不能、と
ファンクショナル界隈の連中って、なんでか理想論ばっかなんだよなぁ
コンポーネント初期化時に一回、何か処理をしたい、って自然な要求に直接答える術がない
useEffectという本来違う目的のためにあるものを、使うしかない
これがファンクショナルの限界
例えばコンポーネント初期化時にログを追記したい、とかな
「状態維持する」って考えじゃ実現できねえ処理なんざ、世の中にはいくらでもあるんだ うわあ・・・
ID:3dlOBCKi
ttp://hissi.org/read.php/tech/20211118/M2RsT0JDS2k.html >>213
いや、ファンクショナルの限界
ファンクショナルでは本来の目的から外れた使い方をしなければない
初回だけ処理したいだけなのに、状態を維持するファンクションを強要される こういう残念な人が出てくるのは公式サイトのドキュメンが悪いせいもある
元がクラスコンポーネント時代に作られてhooksは後付だからuseEffectがライフサイクルで説明されてしまってる
作り直してる新しいドキュメントでは最初からhooksで説明されるから勘違いおじさんが撲滅されるといいな >>194
webpack-dev-server知らんのは流石に論外やろ 関数型のテクニックを使ってるってだけで、やってることはただのオブジェクト指向なんだよな
所詮は構文の違いでしかない
属性を使うかuseStateを使うか
Reactにコールバックをどうやって教えるか
それだけだ
オブジェクト指向ユーザーは、素直にクラスを使ってそれを実装する
関数型ユーザーはやってること同じなんだが、イキがってフックとか使いだして、読み手を混乱させる
JavaScriptの黎明期にプロトタイプベースのオブジェクト指向を使うか、クロージャベースのオブジェクト指向を使うかで揉めてたのと、同じ構図だ
クロージャは関数型で発展したツールだが、実現したい事は結局、どっちもオブジェクト指向だった お前がそう思うんならそうなんだろう お前ん中ではな オブジェクト指向のテクニックを使ってるだけでやってることはただの構造化なんだよな
所詮は構文の違いでしかない
こうですか
最後は全部ただの機械語ですしね! 例えばさ、
ちょっと複雑なコンポーネントを作ろうぜ、ってなったら、誰だってプログラムを分割するだろう?
function useMyForm () {
// 略::フックを使った汚いコード
return { /* 美しいオブジェクト */ }
}
function MyForm () {
const f = useMyForm()
return <…..略
}
useMyFormは何をやってるかというと、reactのフックを使った汚いコードを隠蔽して、
代わりにエレガントな形を持ったオブジェクトを生成して返してるんだね
詳細をカプセル化して、外から見て美しいオブジェクトを作る
これはオブジェクト指向の基本にして、真髄
ファンクショナルのツールを使ってるだけで、やってることはオブジェクト指向、とはこういうこと
それで、賢い人はこの匿名のオブジェクトに名前を付けて、さらに理解を助けるわけだ
例えばclass MyFormBehaivorとかね
で、MyFormはMyFormBehaviorを継承してrenderを付けるだけ、だな、とすぐに気付く筈だね
結局さ、同じなんだよ、やってることが
同じなら、見た目に読みやすい方がいいに決まってる
で、読みやすいのは断然、オブジェクト指向
QED ボタン連打するけしからん奴対策の定番ライブラリ教えてよ
送信フラグ管理はもう疲れた
あ、いちおクロスプラットフォームのライブラリでヨロ ボタン押下で実行されるのをステートの値をtrueにするのみのsetAnyState(true)とかにして
実処理を
useEffect(()=>{if(anyState){
// 実際したい処理
setAnyState(false)
}},[anyState])
にしとけば連打されても大丈夫じゃね? ボタンが押されたらボタンをdisabledにすればいいじゃん それだとめっちゃ高速にダブルクリックした場合多分イベント2回来る場合ある function useMyHook() {
const [a, setA] = useState(0);
const [b, setB] = useState(0);
return {
foo: () => a+b,
bar: () => a-b,
};
}
function MyComp () {
const myhook = useMyHook();
useEffect(() => {
if (myhook.foo() > 100 && myhook.bar() < 20)
hoge();
}
}, [???]);
return <Aaaaa />;
???はどう書くのが正解?
推移的に依存してるのはa, bだがa、bには直接アクセスできない useMyEffectもuseMyHookでやるべきじゃねーの
それができないならuseMyEffectを
foo: useCallback(() => a+b, [a, b]),
bar: useCallback(() => a-b, [a, b])
とすれば[???]は
[myhook.foo, myhook.bar] >>236
1行目訂正
useEffectもuseMyHookでやるべきじゃねーの function MyComp () {
const vm = useMyCompViewModel();
return <略 />;
}
MyCompのユニットテストする時ってどうしてる?
つまりuseMyCompViewModelをインジェクトしたい時 >>241
d
でもこれフックのテスト用なのでは?
そうじゃなくフックをモック化してコンポーネントをテストしたい テストだけならこんなんで十分じゃね
function MyComp (props) {
const useViewModel = props.useMyCompViewModel || useMyCompViewModel
const vm = useViewModel();
return <略 />;
} >>243
なるぼどなぁ
これで少しやってみよかな サードパーティコンポーネントが状態や副作用を持っているがこれを除去してステートレスにしたい
どうすればいい?ソースコードを書き換えるのは無しで function IWantEasyTestableComponent(props) {
return (<View>
<FackingStatefullComponent foo={props.foo} />
<MyAwesomeStatelessComponent {…props} />
</View>);
}
こういうの、どうすりゃいいんだ?
野良ライブラリはどれもこれもアマチュアが好き勝手作ってるから、利便性はともかく品質のムラが大きすぎる
できれば使いたく無いが、使う前提で予算と工程を組まれる
オープンソースのダークサイドやね jest.mock('path/to/FackingStatefullComponent') >>249
ソースコードの書き換えとどう違うんだそれ? 依存関係をインターフェース等で明示的に分離してインジェクションするポイントを作るという考え方ではなく
モジュール自体を上書きしてしまうことで無理やりインジェクションするということか
違和感が強いがこれがJavaScriptの文化と思って受け入れるしかないか LogBox邪魔すぎる
機能OFFにできんのかコレ 状態、副作用は親コンポーネントに持たせるべきか
子コンポーネントに持たせるべきか コンポーネントの用途に依る
基本的にはコンポーネントで独立してる方がいいと思う
ちゃんと精査すれば全体で管理しなきゃいけない状態ってそんなに多くないはず 以前は
親(コンテナ)コンポーネントで状態管理
子(プレゼンテーショナル)コンポーネントは表示だけ
ってのが流行ってたが廃れたな
再レンダリングが発生しやすいせいかな まあケースバイケースになるか
そこそこ複雑な入力ページなんだけど
親に状態を持たせると不定個数の状態の扱いがやりにくい
子に状態を持たせると親への通知がやりにくい
どっちでやってもスッキリしない 入力フォームなら素直にreact-hook-form使え ほぉん
なかなか便利そう
どこまで複雑な入力ページに耐えられるか気になるところだけど
単純なフォームならこれで良さそうだ React完全に理解したがパフォーマンスの上げ方がわからねえ 完全に理解した=何もわからんだからな
チョットでかる=世界一わかってるだし ブラウザデバッガで見て出てるエラー消すところからかな
あとreact-router使わんとページ遷移の度にDOM読み直しとかも効率悪い事この上ない Reactの優れたイディオム、デザインパターンまとめたサイト、書籍、教えてよ react nativeのパーツかわからないんですけど
画面の下から出てくるダイアログってどのモジュールを使えばいいんでしょう?
ttps://i.imgur.com/FuvGKCx.jpg reduxでプレーンな只の関数でstate参照したい時ってどうすれば良いの?
reducersでもactionsでも無いから直接stateは見えない。コンポーネントじゃ無いから
store.subscribeもuseSelectorも出来ないgetState()もない。
やりたいことは、Webの初期表示でstate.env{}の中にブラウザの種類・バージョンとかOSの種類とか入れてるけどそれを単純に参照する関数が書けない
stateはreadOnlyで更新しないから見えればOK
export const seeStateAndDoSomething() {
const { env } = getState() ; // これは出来ないけどコレっぽい処理したい
if ( env.browser == 'firefox' ) {
...何かの処理
} else if ( env.browser == 'chrome' ) {
}
);
どうすりゃ良いの?おそえて。 React Nativeはオワコンらしいですが
Reactは使う価値ありますか?
教えてエロい人 >>268
すいません。
パソコン初心者です。
アドバイスお願いします。 これから勉強するならFlutterの方がいいですか? create-react-appで、npm run buildしたのですが
manifest.jsonのみがbuildフォルダーにコピーされないです・・・
回避方法ないでしょうか? Reduxのストアにクラスっぽいオブジェクト(プロパティ+関数)入れようとしたら
non-serialize objectがどうのこうのとエラーになった。
そもそも何でシリアライズなんかやろうとするんだ? なんかもっと決定的な感じのフレームワーク出ないのエロい人? reduxの根本が不変性をベースにしてるんだが
でないとシャロー比較とか成り立たない
たいして有用じゃないがタイムトラベルも不変性前提の機能
そのへんちゃんと理解してから使った方がいいよ そんなどうでも良い概念を使用者全員に押し付けて来んなよ。
単にreactでアプリをリプレイスで作ったら状態がコンポーネント単位で持たれて、
アプリ単位で持ちたいな、と考えたらReduxが一番人気だよって事で採用しただけだ。
不変性?(w) プログラムが変数に余計な変更加えなければ何もしなくても担保されてるだろw Ruby on Rails の作者・DHH の動画では、
React, Vue.js とか、規約だけのフレームワーク・Stimulus も使う >>283
すでに280に書いただろが
もっともシャロー比較のために不変性が必要というのは話が逆で不変性が前提としてあるからシャロー比較が機能するんだが
もっと言えばreduxは関数型のスタイルを「選択」して全体が作られてる
だからステートやアクションは不変に、reducerやselecterは純粋にすべしってこと
それがreduxの設計意図
一番人気と聞いただけで飛びついちゃった上っ面君には関係ない話だけどな >>284
DHHってフロントエンドでは間違いしかしない人だからスルー推奨 >>285
だから全てのアプリがシャロー比較とかタイムトラベルしたい訳じゃないだろって話してんだがw?
まあ、余計な機能をテンコ盛りに詰めて利用者に強制したから、別の実装が出たりreactが自前実装して
見捨てられるんだろうけど。Reduxに期待する事はFluxのあの図を忠実に実装する事だけで余計な機能は付けるなよ
>一番人気と聞いただけで飛びついちゃった上っ面君には関係ない話だけどな
飛びついたのは俺じゃなくて俺が使ってるミドル作った人だけど、まあ、あのアプリの規模(デモレベル)
でそんな面倒臭いシステム使ったのなら、理由はそんなところだろうなと。
Reduxはマジあかんな。費用対効果が悪すぎる。
コスト意識の無い潔癖な学者か研究者が作ったシステムって感じがするね。 >>287
全てのアプリがしたいかどうかじゃなくてredux使うアプリはその流儀に従うしかないって話なんだがわからず屋だな
それが嫌ならredux選ぶなっつーだけの話だ
ちなみにシャロー比較はreact.memoなどreactエコシステムの共通項だから全てのreactアプリ開発者が身につけておくべきことだけどな
だいたいreduxの元の作者が今はreactコアチームの主要メンバーでredux不要化を進めてる張本人だし Deanin, 1/10、15分の動画
Setup A Ruby on Rails 7 API With React JS
https://www.youtube.com/watch?v=sh4WrNGDvQM
WSL, Ubuntu 20.04, VSCode(Remote WSL)
Ruby 3, Rails 7 のAPI モード、React, Axios
Railsのscaffold で、簡単なデモ。
この兄ちゃんは、きれいな英語を喋るので、翻訳も分かりやすい >だいたいreduxの元の作者が今はreactコアチームの主要メンバーでredux不要化を進めてる張本人だし
害悪をまき散らした張本人だな。
マジであの生鮮性を何故実装して広めようとした事は理解に苦しむ。
J2EEとかhadoopとか(多分将来的にk8sも)生産性が超絶に低い潔癖システムが消えてなくなった事例から全く学ぼうとしないんだな。 ReactでPOSTメソッドだけを受けるアプリ作るのはどうすれば良いんでしょう?
"react POST method "でぐぐってもfetchを使えとか、何故か投げる側の処理ばかりが出ます。
webサーバーには何も入れてないので、npm start で動くサーバーと思しき物はreact-scriptsの筈です。
POSTメソッドだけに紐付いたコンポーネント書きたいのですが… GETとPOSTの違いを質問するだけで、
アレな人を面接から排除できるし、簡単だな
これで95%ぐらい排除できるし いやいや、この場合はクライアントとサーバの違いを質問するところからだろ…… あれ?Reactってサーバーサイドで動く処理は一切かけないの??
Next.jsとかあるから、かけるもんかと思ってたけど。 Next.jsってそれっぽい処理あるのね
React勉強中でAPIサーバ別で作るかって思ってたけどNext.jsで事足りそう Next.jsのサーバサイドはpages以下のページコンポーネントに対応するGETリクエストを受けたときだけそのページコンポーネントをレンダリングする(SSRの場合)
POSTを処理するにはAPIルートを使えるがこれはReactコンポーネント関係ない Ruby on Rails は、React, Bootstrap が多い
他には、Vue.js, Stimulus, jQuery
Bulma, Tailwind
Rails にはHTML ではなく、JSON を返す、API モードもある prettier以外でReact hookでつかえる
フォーマッターで何か良いの無いでしょか? webサイト作っててログイン名とか持ち回りたいんですけど、usestateとかpropsとかで持ち回るよりlocalstorageとかsessionstorageとか使えば良いのでは?と思うのですが何か問題あったりする? なぜその程度の情報をそこに保存しようと思ったのかを知りたいね どうせ他にも持ち回る情報はあるのだからちゃんと管理した方がいいよ
どっちしろuseLocalStorageみたいなフック作ることになるんだし Ruby on Rails では、セッション情報を何を使って実現しているかは、あまり意識しない。
各デバイスを自分でコーディングする事もない
4KB までなら、ブラウザのcookie だし、
それ以上なら、Rails のキャッシュか、データベースとか
フレームワークを使わない人は、自分で調べてコーディングするから、
何十倍も時間が掛かって、なおかつ低品質な実装しかできない React初心者だけど画面のDevelper ToolsからReactコンポーネントが
どれなのかってわかりにくいよね?
ブラウザからHTMLを見るとどれがReactコンポーネントの塊なのかわかりにくいし
Reactコンポーネントを組み込んだHTMLのビューファイルのソースコードを見ると
配置されているコンポーネントが何なのかわかりにくい React DevToolsというのがありましてん Reactってちょっとした実装するとすぐパフォーマンス悪くなって
不要なれだリングを抑制するのに苦労するじゃん
これ逆にで、全て手動でレダリング指示する方式には出来なかったん? >>307
recoil使えばええんやない?それで足りんかったらrecoil-persistも react-bootstrapの"esm"ってどこの馬鹿が付けたんだ?
RowとかColとかを自動インポートするたびにesmが付きやがる・・・(怒
それならreact-bootstrap-esmにでもしてreact-bootstrapとは分けろよ
とんでもねえ馬鹿野郎が作っちまったな スマホアプリと連動するWebアプリを開発するために
html, css, js, ts, react, redux, material-uiなどについて現在勉強中
「組み込みの経験値があるから、Webアプリ開発なんて楽勝でしょwwwww」とか思ってたけど
技術選定を含めて二週間かかってもまだ開発に着手できてない
もう1週間はかかりそう。かなり敷居が高いな バックエンドはfirebaseとapp engineを使うつもりだから簡単なはずなんだけど Material-UIもv5になってv4の頃より大分使いやすくなったし選択肢に入れてもいいんじゃない? >>319だけど、やっとまともに開発を進められるようになった
まだ手が早く動かなくて辛いわ reduxを使うにしても、UI側だけで使用する状態の保持はcontextでやった方がいい感じかな
あくまで個人的感想の落書き gifjsってライブラリをReactNativeでも使えるようにしようと色々いじくってます。canvasが必要なのでreact-native-canvas入れてみたけどgetImagedataが遅すぎる...
webviewで実行したら改善するかな??もしくはなんか違うやり方あるかな?? 組込みやってて流れでreactで自社内で使うwebアプリのフロント側
作らされる羽目になったのですが素人がreactとjs学ぶのに
定番みたいな書籍やコンテンツありますか?
バックエンドはやりませんがpythonのfastapiです。 reactとかってソースにコメントって
あまり書かないほうがいい的な暗黙のルールってあります?
読まれちゃうから?
今のプロジェクトのソースにコメントがやけに少ない気がしてて、、。 ないです
トランスパイルしたら消えるのでしっかり書きましょう propsで受け取ったデータを
内部で更新するときに
useStateすると思うんですけど
そするとpropsの変更が無視されるんですけど
その時のベストプラクティスって何ですか? ベストプラクティスかは知らんけど中間のコンポーネントで親からのpropsが変わったら子のkeyを変える方法を使ってるな reactはtypescriptが必須なのでしょうか? Reactが流行っていないから、過疎っているんだよ reactの求人は多いですけど、実際にはどうなのでしょうか。 >>341
そうなのですか。
今、javascriptとjQueryの勉強をしてますが、この2つだけでも大変ですね。 Reactのメリットを教示するには結構ガッツリ使いまわせる様な大枠を一回つくってしまわないといけないんだよな
それができるまでのハードルは結構高いけど一回作ってしまえば色々再利用性が高くて開発効率が各段に上がる JavaScript関連技術でwebアプリを作るならreactは便利でしょうか? Reactやった後にAngular触ると1個コンポーネント作る手間が煩わし過ぎる ブラウザ実装の生WebComponentsも大概メンドクサイからオヌヌメ 最近フロントエンドエンジニアに転職した元cobolerだけど2つ質問したい
・状態管理ライブラリって今はReduxが主流で公式はtoolkit推してるけど、toolkitってrecoilと変わらなくね?recoilに比べてどういうメリットがあるの?
・クラスベースの記述って殆どしないの?ベストプラクティスは関数ベース? toolkitはReduxで使い勝手が悪かった機能を改良したもの。(asyncに対応させるためにthunkとかsagaが必要だったりとかの)
recoilのほうが新しく記述もシンプルで見通しが良くなる。stateのset/get両方に対応。ただしまだexperimental
https://www.npmjs.com/package/recoil
Recoil is an experimental state management framework for React.
公式は関数コンポーネント+フックを推奨
https://ja.reactjs.org/docs/hooks-faq.html#should-i-use-hooks-classes-or-a-mix-of-both
フック、クラスのいずれを使うべきですか、あるいはその両方でしょうか?
準備ができしだい、新しいコンポーネントでフックを試すことをお勧めします。 >>354
ごめんクラスコンポーネントと関数コンポーネントの違いは分かってるんだ
例えば、1+1を計算する関数をクラスベースで定義すべきか関数ベースで定義すべきか
的なことを知りたかった! JS/TSでクラスはほっとんど使わない
使うのは独自のErrorクラスくらいだな
メソッドというより関数をプロパティとして持つオブジェクトはよく使う
でも基本は単なる関数 React実践の教科書、2021
この本には、クラスは出てこない。
すべて関数 なるほどなるほど
仕事でcobolとvbaしか使ったbアとなかったかb辜Iブジェクト試w向的な記述自荘フ馴染みなかっbスわ
Reactに関しては、本やらネットやらで関数しか使わねみたいな記述は多く見てたんだけど
今配属されてるプロジェクトではクラスベースの書き方が多く見られたから
現場では何だかんだ使うんだ!って勝手に納得してたけどそうじゃないのね
元々phpやらjavaやらやってた人たちが分かりやすいからって使ってる感じぽいな JSのクラスと
Reactのクラスコンポーネントと
Reactの関数コンポーネントの区別出来てる?
ちなみにReactのクラスコンポーネントはオワコンだけどね >>361
・jsのクラス…いわゆるオブジェクト指向の考え方におけるクラス。継承やらなんやらできる。但し、プロトタイプベースであるjsではほとんど使われない
・クラスコンポーネント…super(constructor)みたいな書き方してstate管理するやつ。thisとか使いまくって見通しクソ悪い上にhooks使えないゴミ。progateや公式チュートリアルはこの書き方してるので初心者は騙される。
・関数コンポーネント…スタンダードなreactコンポーネント。読みやすい。神。
こんなイメージだけど合ってる!? >>362
Reactのクラスコンポーネントは無くなるんであれこれ考える必要ない
関数コンポーネントの一択だ
JSの方は好みだな >>360
> Reactに関しては、本やらネットやらで関数しか使わねみたいな記述は多く見てたんだけど
> 今配属されてるプロジェクトではクラスベースの書き方が多く見られたから
> 現場では何だかんだ使うんだ!って勝手に納得してたけどそうじゃないのね
Reactだから関数しか使わないということはないという認識
本やネットで見かけるサンプルコードはそのへんは主眼じゃないから参考にならんでしょ
クラスベースを頭ごなしに否定するものではないと思うよ Reactコンポーネントに関してはクラスベースを頭ごなしに否定して構わない >>364
頭ごなしに否定する気はないんだけど
(jsの)クラスベースの記述するメリットってどういうとこがあるの?
配属されたプロジェクトのコードを初心者目線で見てクラスベースと関数ベースが混在して読みにくいな、って印象なのよ Reactに関しては関数コンポーネントしか使わないけど、それ以外の部分では臨機応変に使うのみよ。まぁそれでもclassの出番はかなり限定されるけど…… プロジェクトメンバーにどうして混在してるのか聞いてみた? jsにおけるclassの出番って、大量に作成し、なおかつ副作用があるオブジェクトがある場合くらい……。 話の流れで関数コンポーネントかクラスコンポーネントかの話は終わってるのは分かるっしょ Reactなので将来容赦なくクラスコンポーネントが無くなるかサポート切ると思う >>368
うん
「本当はよくないんですけどね~~」
的なことを言ってたよ
他にも
・propsのバケツリレー
・コールバック関数使って 子→親へのprops逆流(これが一番酷い)
・アロー関数とnamed functionの混在
・typeとinterfaceの混在
・mui使ってるのに無駄にemotionでカスタムコンポーネント作成
等々………
どの現場もこんな感じなのかなぁとは思ったりするけど
やっぱ立ち上げ段階でコーディングルールやら設計やらある程度固めとかないとスパゲッティ化するんだね プロジェクトメンバーが現状を問題と捉えてるならどういう方針でコードを
書いていけばいいかお伺いを立ててそれに従うべきでしょ
もちろん自分の意見があるならそれも伝えて >>373
Java屋PHP屋Cobol屋の混成チームでコーディングルールも設計もフワフワとか地獄やん……。
PMがフロントエンド舐めてたのかな。 >>374
リモートだけどSESだから元請けに当たる人に対して
ガチでWEB開発業務1ヶ月目の俺からは意見しにくいんよ、、(笑)
スタイリングぐちゃぐちゃだったのはさすがに言ったけど
でも言うとこは言ったがいいね。ありがとう。
>>375
アジャイルってこんなもんなんじゃないの?知らんけど(笑)
でもしっかりしたreact案件でちゃんと現場のこと学びたいとは思うわ >>362
jsでクラス使わないことは多いが、だからといって今時 __proto__ なんて直接使わないから
プロトタイプベース云々は関係ない。 >>373
React実践の教科書、2021
基礎はこの本で良い。3日で読める
propsのバケツリレーは、
グローバルState である、useContext を使うと書いてある
これ以上に複雑なものは、Redux, Recoil, Apollo Client など
useMemo など、use何々にはどういう機能があるか、すべて見た方がよい Reactビギナーズガイド ――コンポーネントベースのフロントエンド開発入門
Stoyan Stefanov, 2017
この本には、createClass と書いてあるけど、
2017年6月には非推奨になっている
var MyComponent = React.createClass({
render: function() {
return React.DOM.span(null, "カスタムコンポーネント");
}
}); なんでそんなにクラスコンポーネントの話にこだわるの? presentationalとcontainerに分けて書くといいよ、って本かなんかで読んだことある。今のプロジェクトでも実践されてる。
で、その辺の構成の都合上、仕方なくコールバック関数使ってpropsの値を子→親に伝播させてるけど普通なの?
一般的には状態管理ライブラリ使うべきだと思ってるけど認識違う? プレゼンテーショナルとコンテナに分けるのはRedux全盛時代の流行でhooks以降は廃れた
それとは別に親から子にコールバック渡すのは極めて普通
useReducerなんかそういう使い方がほとんどだろ
その親がほとんどルート(いわゆるAppコンポーネント)に近いくらい上位にいるならそれはグローバルステート >>382
へー!なるほど!
その経緯は知らんかったわ!ありがとう
propsの大原則として親→子→……
があって、それを解消するためのグローバルステートと状態管理ライブラリ、という理解なんだけど
グローバルステート使わずに普通にコールバックして直接、
子→親、孫→親みたいな渡し方してるのに違和感感じてたのよ
現場では割と普通のことなのね え、一つのコンポーネントを表示とロジックに分けるやつもう廃れたのか…
今はどういうのが流行りなの? ひょっとしてReact Routerって仕組み上ブラウザキャッシュ効かない? >>385
ロジックはhooks
データ取得もhooks (swrやReact Query)
そのデータ取得hooksはデータを表示するコンポーネントで呼び出す
これは特にGraphQLではフラグメントコロケーションと呼ばれる
GraphQL以外でもRemixがコロケーションを実現してる
総じて変に分類するより凝集度を高くする方向に進化してる >>387
例えば複雑な条件と処理に応じた多様なウンコの画像表示するコンポーネントShowUnkoがあったとして
その条件や処理をShowUnkoの中に全部書くのが流行りなん?
presentationalとcontainerの例だと
複雑な条件と処理をcontainerに記述して
算出した結果をpresentationalに渡してウンコの画像が出るけど
今の流行りは色々なライブラリ駆使してそれらを一つに纏める、ってこと?
…まぁ少なくとも個人開発してる頃は後者のが全然やりやすかったけど >>386
くっそ短絡的だった。サイズがデカイjsファイルだけURL固定すりゃ良いだけだったわ…… >>388
いやいやいやロジックはhooksって書いたじゃん
複雑な条件や処理とやらはuseUnkoに書いてShowUnkoはそれを使う Ruby on Rails では、コントローラーの肥大化を防ぐために、
Skinny Controller, Fat Model を推奨した。
その結果、モデルが肥大化した
そこで今度は、モデルの処理を減らすために、
Form Object, Service Object へ処理を分けた
また表示処理は、Presenter へ分けた。
それで、Form Presenter, Model Presenter が出来た >>390
コンポーネントにロジックを記載するのではなく
カスタムhooksとして切り出すってこと?
理解力乏しくてすまん React実践の教科書、2021
この本には、カスタムフック・自作のHooks も書いてある
ロジックをコンポーネントから分離し、複数コンポーネントで再利用する。
共有ロジック >>393
hooks限定である必要はないと思うが... >>395
元々コンテナコンポーネントに書く必要がないようなロジックの話をしてるつもりはないんだよなぁ
React無関係なロジックを普通の関数に切り出す話ならReactスレで話さなくていいだろ
状態やライフサイクルなどReactに依存したロジックを切り出すならuseStateやuseEffectを使う関数になりそれはカスタムhooksと呼ばれるということ ステートレスなロジックも意味なくhooksとして?実装するとでも言うのかい? ごめん、一番聞きたかったのは
コールバック等使ったpropsの逆流(リフトアップ?)のことなんだけど
例えば、ダイアログ等実装する場合recoil使ってstate管理すれば簡単に実装出来ると思うんだけど
わざわざリフトアップする必要ってあるの?? 俺の場合はコントロールの状態は極力propsで渡して
そのコントロール起因で発生した状態の変更は
そのコントロールの外部からディスパッチして
またコントロールのpropsとして再投入するパターンに落ち着いた 全部props渡しはどのコンポーネントが何のデータに依存してるか明確にわかるのが好き propsて受け取った状態を
内部てstateとして別管理すると嵌まるパターンが多いね React勉強中です
テーブルが例えば最大行数20行として、新しいデータを取得するたびに先頭行に追加、末尾データは削除、というのをしたいです。
以前直接DOMを操作していたときは、テーブルのElementに対し、insertRow()、deleteRow()を行っていました。
これをReactでやろうとした時、テーブルの各行のデータを配列で持っているとすると、下記のようにmapを使って各行のHTMLを生成するというやりかたがあるかと思いますが、
この場合は行の追加の度に全行が再レンダリングされてしまいますよね?
const table_data = ['a', 'b', 'c', 〜]
return(
<tbody>
{
table_data.map((val) =><tr><td>{val}</td></tr>)
}
</tbody>
)
前述のような先頭行に追加、末尾行は削除、というのをReactでやるとすると、どいういう感じの処理になるのでしょうか?
ヒントをいただけると助かります。
まずは、1行ずつをコンポーネントにするのは必須ですかね? >>402
> 先頭行に追加、末尾行は削除
keyを調べれ
> 1行ずつをコンポーネントにするのは必須
んなこたぁない >>403
ありがとうございます。
なるほど、keyが同じで中身が変わらなければ再レンダリングされないのですね。
だから必ずkeyを付けるんですね。 keyはどのみち付けないとWarning出るね
バックエンド連携とかどうするつもりなのか知らんけど
普通に先頭20件だけ表示するように指定してやって
useEffectでtable_dataを監視してやればすんなり行きそうだけどなぁ >>405
ありがとうございます。
useStateでテーブル用データの配列を管理し、データ取得されるたびにその配列の先頭に追加、sliceで20件だけ切り出し、という方法でやりたいことはできました。
ユニークなkeyを付けることで再レンダリング対象が更新部分だけになるのも確認できました。
データはWebSocketで受信して取得しますが、どなたかのサイトで紹介されていた、コンポーネント内のuseRefでWebSocketオブジェクトを持ち、useEffectで初回時のみに接続するという方法でとりあえあず動作しました。 react native詳しいニキ教えて
下部に表示されるメニューバー(以下、Menu)のコンポーネント作ってて
ページによって表示/非表示の設定をしたいんだ
各ページコンポーネントでMenuを直接呼び出すような作りにすれば確かに実装出来るけど
ページが切り替わった時点でアニメーションが途切れるし、なによりナンセンスな気がする
で、次の案。
App→Main→各ページという構成を取ってるけど
MainでMenuを呼び出すようにした。
で、これをRecoilで管理するboolean型のグローバルstateで表示/非表示にする。
あとは各ページの初回レンダリング時にstateの値を書き換えるだけで解決……と思ったけど
前のページにバックしたときに改めてstateの値が書き換わらないんだ。
これを踏まえて何かいい方法ないですか? 知らんけどrecoil-syncってのがあるらしいな知らんけど Metaが倒産したらReactどうなってしまうんだ?ってレス見たんだけどほんとどうなってしまうん?
誰かに買われるとか??? Vercelは確実に欲しがる。Remixを買ったShopifyも欲しがるかも。Googleが掻っ攫うかもしれない >>412
ありえそう
OfficeとかReact Nativeやしな >>414
入ったプロジェクトがこんな状態になってたらマネージャーかリーダーの判断力があやしすぎて即転職考えるかもしれん ClojureScriptでReact使うのがまんまそんなだった
Lisp界隈の人はなんでもS式だからな tic-tac-toe。今更変わらないのはわかってるけどpure jsで何の不便もないじゃん。
https://jsfiddle.net/nwmeqbL4/ reactでjsx使わない話なんだけどダメ?
タグ手打ちで補完が効かないhyperscriptとかもっとマイナーななんとかhelperとか
誰も使ってない怪しいライブラリに頼らずとも自分で200行コード書くだけで
jsx使わないで済むのは自分は衝撃だった。
見たことない構文だけどただのjsなんで補完もインデントも問題なし。閉じタグ書かなくていい。
[div, {className: 'game-info'},
[div, status,],
[ol, moves,],
], >>422
チームで合意が取れてれば良いんじゃないかな
自分は好みとかあまりなくて標準だったりプロジェクトだったりに適応するのが好きだから
プロジェクトでそうなってたら合わせるかな
もちろん自分が一からやるなら現時点で大勢が使ってる標準的なjsxを使うし html in jsはカッコ地獄で使い続けられないと思った
mapや三項演算が組み合わさると、あっという間にreadabilityも破綻
jsxは < > 構文なのでカッコに関してはマシ jsx ももはやただのjsなんで補完もインデントも問題ないんだよなあ
閉じタグはあった方が見やすいしこれも補完聞くから書くのも手間じゃないし ReactがFB内で生まれたのがES5より前だからかJSXでclassやforを属性名として使えないのはそろそろ修正してもいいと思うわ 逆にJSの言語仕様としてのクラスが要らんのやないかって感じするしな >>429
PreactではJSXでclass属性使えるからReactが使えないのは単に怠慢ちゃうか
>>430
Rustのstructとimplの関係とかオブジェクトとprototypeの関係に近いし、classなんて要らんかった感がある。なんもかんも関数にnew付けるとコンストラクタになるっていう全く直感的でない仕様が悪かった reactでjsx使いたくないなReact.createElement使えばすむだろ
pure jsだしreact自身がメンテナだぞ class使わんかったらええしjsxも受け入れればええやん
中途半端に色々俺ルール入れようとするからプロジェクト通したコードがグチャグチャになるんだよ
ガタガタ抜かさずに読みやすいコード書け React.createElement() は、見たことない。
クラスなのか?
今は、関数しか使わない >>435
JSXをトランスパイルするとそれが出てくる
というか前はそれになってた
今はもちっとサイズが小さくなるコードにトランスパイルされる フロントエンドはAIとローコードにより死んでいきそう フロントエンドの連中が死んでいったら愉快すぎるだろうな。 管理画面作れるローコードツールやばいで?
t-wadaさんの会社が出資してるやつ
ガチでフロントエンドいらんw 周りが適性なさすぎて消去法でバックエンドやるハメになり
苦労もあったが経験しておけて良かった みんなuseStateのとき以外でset~って関数名付けてる? Reactが始めてなので変な質問かもしれません。
React.Componentを継承したクラスを作成し、これを「new」した時点でbodyの最後に描画したいです。
具体的にはmodalのクラスなのですが、
import modalClass from './modalClass';
const hoge = new modalClass(); //この時点でbodyの最後に描画されて
hoge.show(); //これで描画されたモーダルが表示される
だけでモーダルを表示したいです。
constructor中でrenderを実行して、戻り値をReact.Domでbodyの最後に置換すれば可能な気がしますが、
このような使い方は一般的でしょうか?
htmlに「<modalClass />」の記述をしたくありません。 >>448
一般的ではないね。ReactコンポーネントであればJSXに<Modal />などと書いておきReactのライフサイクルの中でstate更新して表示/非表示を制御するのが一般的。
あとDOMツリーに要素を「追加」する操作を「描画」と呼んでると今後の理解の妨げになる可能性があるから一回整理したほうが良いかも。(Reactはライフサイクルの意識が結構大事なため) はい、一般的ではないのは十分承知しています。
ライフサイクルなどを無視してHTMLの管理と描画のみにreactを使用したいと考えています。
ソースコードとしては下記で行けたのですが、このような使い方が一般的に許されるのかが不安です。
class ExampleComponent extends React.Component {
constructor(props) {
super(props);
const element = this.render();
const container = document.createElement('div');
document.body.appendChild(container);
ReactDOM.render(element, container);
}
show() {
//モーダル表示のDOMの操作
}
render() {
return (
<div>
/** モーダルのHTMLソース **/</div>
);
}
} 動作するのは確認できたので、あとはプロジェクトリーダーの好み次第ですかね。
これが許されればサーバ側のviewでHTML管理しなくて済むようになりますので
コンポーネントの使いまわしが楽になるのですが。
javascriptのみで完結できるので。 Reactをrender()するHTML要素を動的に追加するのはありだと思うよ
でもそのロジックをReactコンポーネントに入れる必要はないな
ユーティリティな関数でそれをすればReactコンポーネントはクラスではなく関数コンポーネントにもできるし まず動くようにしたのは素晴らしいけど、たぶんリーダーかは指摘が入るはず。 最初はお手本通りrender関数とコンポーネント挿入関数に2ファイルに別けてたのですが、
一機能実現するために手順を踏んで2ファイル使うのが解り辛いかなと思いました。
作った自分は解るのですが、引き継ぐ人にはシンプルな手順で使えるようにしておきたいです。
render関数とコンポーネントの挿入関数を試行錯誤して一つのファイルにまとめたら >>450のようになりました。
>>450なら
import ExampleComponent from './examplecomponent';
const modal = new ExampleComponent ();
modal.show("メッセージです", "タイトル");
だけで済むので、クラスのusageに書いておけば利用手順も簡単でどの画面でも使えると思います。
reactの定石からは離れますので、やはりreactのプロの目から見ると違和感あるのですね。 Windowsアプリのメッセージダイアログみたいにメソッドひとつで呼び出せる手軽さを実現したいって理解でいいのかな あちこちに<ExampleComponent />追加したくないってことかな?その場合はProviderやContextを使うのが正式なやり方になると思う。
レイアウトに1個<ExampleComponent />追加する程度はふつうにやることなのでそれはみんなわかると思う。 >Windowsアプリのメッセージダイアログみたいにメソッドひとつで呼び出せる手軽さを実現したいって理解でいいのかな
はい、それであっています。
>あちこちに<ExampleComponent />追加したくないってことかな?
はい、ReactのメリットはJavascriptにHTMLを書ける事なので、HTMLとの依存関係を切って
なるべくJavascriptだけで完結させたいです。
とくにモーダルのような汎用的などこでも使うものは、HTMLに<ExampleComponent />を記述させたくないです。 メッセージダイアログ、確認ダイアログ、エラーダイアログなんかの共通系は
どこでも仕込みなしで呼び出したい
あるあるな要求だと思うけどReactではどうやるのが定石なんだろうね レイアウトが必要なコンポーネントは、HTMLファイルにreactのタグを埋め込む方向で理解できるのですが
メッセージダイアログのような画面中のレイアウトが必要無い物については
わざわざHTMLファイルにタグ埋め込んでおく必要ないのではと考えています。
javascriptで動的にタグを埋め込むのが良いと思いますが、タグ埋め込む機能をrender機能のファイルと別けたくないですね。 Railsとかの既存画面にReactでモーダルだけ作ろうって話?
jQueryの代わりにReactみたいな使い方ならその時点で定石から外れてるわな へ?普通にSPA?
それなのにDOMのエレメント作ってrender()呼ぶって?ただのアホじゃん そりゃ動機があって試行錯誤の中でイレギュラーなことをしていて
より良い方法、より一般的な方法はないかという問いかけなんだし 試行錯誤にしても道を外れすぎ
React.renderはReactアプリ(コンポーネントツリー)全体をDOMにマウントするためのAPIで個々のコンポーネントが呼び出すもんじゃない
大抵はフレームワーク的なコード(CRAやNext.js)が呼び出すからアプリからは呼ばない
共通のモーダルコンポーネントはAppコンポーネントなどツリーのルート近くに一つだけ置く
そしてモーダルはそれを開くためのカスタムフックを利用者に提供する
モーダルの開閉制御に使うステートはRedux等のライブラリを使ってもいいしContext + useStateでもいい 試行錯誤ってのはそんなもんでしょ
まして最初にReactに不慣れだと断ってるわけだし
寛容にいこうよ イレギュラーなやり方ということは重々承知しています。
自分のやり方はreactのフル機能を使うよりも、ESM+Reactの機能の一部を使ったやり方になり
Reactの恩恵を受けられない事を承知しています。
その上で使い勝手を選択して、react機能の一部のみを使った開発を行うのもありなのではと思ったりしています。
ダイアログなどの静的なコンテンツについてはreactの機能を全て使い切らなくとも、reactが無くとも実現できますし、
reactの性能を発揮できる開発内容でもないと思っています。
静的HTMLのページをreactで作るのが効率悪いのと同様に、静的なダイアログ程度のものについてもreact使わない方が良いんじゃないかと。
その上で便利な部分(javascript上でHTMLを共有化できる)だけ摘まみ食いしたいです。
reactの専門家から見ると節操無いでしょうが、開発効率や汎用性を考えた場合に
こういったやり方はどうなんでしょうかと意見を」聞きたかったです。 >>466
>>464の提示してるやり方はどう?落とし所としてはいいように思えるけども
あと>>456も1箇所に固定で追加するという方針は近しいように思う
必要なら詳しく聞いてみたら? >>466
結局何をどう作ろうとしてるのかわからないんだよな
Reactで完全なSPAなら最初から449や456が書いてるとおりだし464も同じことを書いてる
しかし451の「サーバ側のview」とか466の「react機能の一部のみを使った開発」なら460に見えるんだよな
それなら452だろう
454で変なこと書いてるけど1ファイル1関数に制限さb黷驍椡じゃなb「んだから2ファイルに分けたくなけりゃ分けなければいいだけ つまり……
・他のreactコンポーネントから利用されるreactコンポーネントを作ってる
のか
・reactで作ってるけど利用する側はreactとか気にしないで使う
なのかどっちなんだという話 >>464の提示してるやり方はどう?
react的にはスマートなやり方なのでしょうが、react使わない方が実装手順を簡略化できるのでメリットを感じないです。
>>・reactで作ってるけど利用する側はreactとか気にしないで使う
の方です。
関わっているプロジェクトがこれからreactに乗り換えような流れなので、新規開発分からreactで作り始めているのですが、
そもそものベースがreactではないので、reactの便利な所だけ利用したい感じですね。 >>470
それを先に言えって話だがそれなら>>452でいいだろ
モーダルを表示する関数だけexportしてreactコンポーネントはexportせずにファイル内だけで使う
ダイアログ表示するたびにDOMエレメント作るなら閉じたときに削除忘れないように
reactのアンマウントも >>471
多分言っている事を理解しました。
reactによるコンポーネント作成と表示する関数は別けたいと思います。
ファイルを別けるのには違和感がありましたが、同一ファイル内で2関数実装して
片方だけexportするなら理想通りです。
一度サンプルソースを作成してリーダーに相談してみます。
ありがとうございました。 実装者しか分からん負の遺産はこうやって増えていくんですね
自己満のためにプロジェクトを良くない方向に進めている自覚を持ちましょう。
あなたのやっていることは時間の無駄です。 だけど、いくらきれいに書いたとしても、後任者がアレな場合、結局、良くない方向に進む(本人たちは満足)なので、どないしようもない気がします
(という現場をよく見てきたので、どないしようもないですね) きれいなだけではダメで意図とか背景にある思想とかそういったものをちゃんと伝えておかないと
今回みたいに定石から外れることを自覚してるならなおさら でも必死こいてゲットしたマイナポイントも結局使わないまま失効するんだろどうせ