26/05/13 21:14:34.79 8lgXfqyf.net
サンプルをちょっと動かしてみただけなので詳しいことはまだ分からないが、ページ遷移すると入力中の状態が全てリセットされてしまうのは前のままっぽい？
もしそうなら、デスクトップアプリを作る際にはあり得ないくらい不便な仕様だと思うんだが。
122:デフォルトの名無しさん
26/05/13 22:03:03.00 hI6qZkKs.net
react使いじゃないから慣れないけど
use_stateした変数を使えば消えないことない
route="/"にTextFieldあってそこに文字いれてて
route="/settings"にnavigateしてから"/"に戻ってもTextFieldの中身は消えてないよ
前のでも114みたいに毎回page.views.clear()して作り直したらそりゃroot_viewの中身は消えるよ
123:デフォルトの名無しさん
26/05/13 22:48:07.14 8lgXfqyf.net
120で念頭に置いていたのはマルチViewのとき（Routerの manage_views 引数がTrueのとき）のことで、Fletのページ遷移はpage.views.clearをしてからpage.viewsのスタックを作り直す仕様なので、その仕様のままなのかということが気になったのね。
実際、リファレンスのRouterの末尾の例「Managed views — full app with NavigationRail」では、Settings の Account にあるTextField の入力内容はページ遷移すると消えてしまっているみたいだし。
それで、シングルViewのときはたしかに、121で言われているようにページ遷移でも大丈夫なのかなと思ったんだけど、試してみるとTextFieldをルートパスより下のパス（'/settings'）に置くと、ページ遷移で入力内容が消えるっぽい。
まだ、全然不慣れなので自分のコードが間違っている可能性もあるが、仮にそうでなければ、消えないのはルートパス '/' にある入力内容だけだったりするのかな。
あとその点は抜きにしても、すべてのTextFieldについて use_state して changeイベントハンドラを書かないといけないならそれだけで大変だと思う。
124:デフォルトの名無しさん
26/05/14 13:09:27.92 vpFBDTpV.net
シングルViewの場合については、TextFieldがルートパス '/' にあるかそれより下のパス（'/settings'等）にあるかを問わず、①入力内容がオブザーバルの属性の値とされているときは、いったん他の画面に遷移した後に戻ってきても入力内容は残っているのに対し、②入力内容がuse_stateで保持されているだけのときは、画面遷移によって消えてしまうっぽい。
ただ、①の場合についても、オブザーバルは、切り替えられるコンポーネントの外側で（コンポーネントより上位で）定義されていることが必要なのかも。
125:デフォルトの名無しさん
26/05/14 19:23:13.39 loEEFON/.net
Component破棄されて再生成されるから初期化されるね
書いてるとおり親で管理するかContext突っ込むんじゃね
126:デフォルトの名無しさん
26/05/15 08:27:48.97 4UBq37Ne.net
コンポーネント関数の名前は、公式リファレンスにあわせてMyComponentみたいなアッパーキャメルケースで書くようにしておいた方がいいのかな。TextFieldを返すコンポーネント関数の名前をtextfieldにしたりもしていたんだけど、そういう命名法はあかんってことか。
127:デフォルトの名無しさん
26/05/16 15:55:31.02 Unfk+73I.net
宣言的UIで行く場合はタブ等についてもRouterでやって下さいってことなのかな。そうだとすると、ベータ版になってからのアップデートとはいえ、けっこう根幹部分の機能追加だよね。
128:デフォルトの名無しさん
26/05/17 07:01:11.46 xW24veJQ.net
flutter自体がオワコンになりかけてるからな
レイオフとかで開発力ガタ落ち
129:デフォルトの名無しさん
26/05/17 10:17:55.87 FhgeLITh.net
土台となるGUIフレームワークの栄枯盛衰については、全然知らないからなぁ。ReactとFlutterは相対的には長生きしそうなイメージだったんだが、そうでもないん？
130:デフォルトの名無しさん
26/05/19 20:29:17.31 RPh0mYKY.net
>>126
Component関数はリファレンス通りにアッパーキャメルケースにしてるわ
131:デフォルトの名無しさん
26/05/29 08:26:00.63 Qbq0yJB5.net
Reactをやったことがないのもあって、create_contextとuse_contextの便利な使いどころというのが今ひとつよく分からないんだが。便利なパターンはuse_route_outletとかで既に個別にフック化されているから、あまり意識しなくて良い？ 今のところ、ミニグローバル変数として使っているんだけど、スコープが限定されるメリットとわかりにくさというデメリットとの間で得失は微妙なのかなと思ったり。
132:デフォルトの名無しさん
26/05/29 10:11:46.23 FGFe5DIW.net
Flet Studio だって。いわゆるプレイグラウンド的なやつかな？ 開発チームは随分精力的だね。
133:デフォルトの名無しさん
26/05/29 18:05:30.12 xfSKxvZO.net
observableあるからuse_stateのこと忘れてもいいんかなと思ってきている
134:デフォルトの名無しさん
26/05/29 19:37:14.83 xfSKxvZO.net
いやいや、use_stateはいるじゃん
set側か
135:デフォルトの名無しさん
26/05/29 23:13:42.72 FGFe5DIW.net
単一のコンポーネント関数内でのみ参照されて、画面遷移時にリセットされても構わないような状態ならuse_state にするのかなと思うけど、たしかに自分もオブザーバブルを使うことの方がだいぶ多いわ。
use_stateってちょっと分かりにくいよね。引数に意味があるのは最初の呼び出し時だけで、2回目以降は保存されたフックの値が返るだけって理解するまで時間が掛かった。
136:デフォルトの名無しさん
26/05/31 16:20:59.10 ry1U618O.net
use_XXX系のフック関数の学習中だけど、これを一通り理解して使いこなしているReact の人って凄いなといつも思う。
137:デフォルトの名無しさん
26/06/01 13:07:47.15 kVwOXar0.net
Border.symmetric のソースは、コードとコメントが矛盾しているようなんだが。Flutterに合わせるならたぶんコメントの仕様の方が正しいよね？
138:デフォルトの名無しさん
26/06/01 15:19:53.62 kVwOXar0.net
horizontal引数、vertical引数の意味についてMargin.symmetricなどと平仄を合わせるようにした（Flutterの仕様から意図的に変更した）ということなのかも。コメントの修正が忘れられているだけで。
139:デフォルトの名無しさん
26/06/01 22:26:39.53 sAQpiy4+.net
イベントハンドラがメインスレッドに変わったんだな
140:デフォルトの名無しさん
26/06/22 23:11:00.38 J24Uog3C.net
Pageの幅や高さを取得する汎用的な方法ってないよね？
リサイズイベントを起こしてもらえればそのイベントハンドラで取得できるけど。
141:デフォルトの名無しさん
26/07/08 09:42:34.41 KyEOwatk.net
汎用的なオブザーバブル型としてValueHolder[T] みたいな型を定義して、スカラ値のオブザーバブルについては全部その型にしているんだけど、設計上何か問題あるかな？
はじめはリファレンスにあるように個々のオブザーバブルごとに型（データクラス）を定義していたんだけど、アプリ全体で何十個もTextFieldやらRadioGroupやらを配置してそのそれぞれについてオブザーバブルで値を保持するのに、いちいち個別のオブザーバブル型を用意するというのはムリだろうと思うんだが。