なぜ宣言的 UI は壊れにくいのか / Why declarative UI is less fragile

Zli × サイバーエージェント 合同LT 2024/07/14 https://zli.connpass.com/event/319572/ ReactやSwiftUIのような宣言的UIの「原理」を、10分のLTになんとか詰め込んでみました。 Reactフックは名詞起点 = オブジェクト指向…

[Magicant]

モードがないといふのは実は嘘といふか、言葉の綾。従来 UI だとモードを表す変数がビューの中に隠されてるのに対し、宣言的 UI では変数が全てプログラマーの手中にあるので御しやすいといふのが宣言的 UI の肝

[otihateten3510]

デメリットにも触れて欲しい

[shingo-sasaki-0529]

宣言的UIを書けるフレームワークでも「モード」の概念を持っちゃう命令的なコンポーネント簡単に作れちゃうから気をつけないとなぁ

[leiqunni]

さっぱりわからない。処理をアトミックにするとかの話？

[rryu]

モードというか状態遷移の状態だと思う。内部的な状態変化とそれを外部に反映させるという二つの処理が必要になるが、単純な同期だけなら追加のコードは不要なので無くなってると思っているだけではないだろうか。

[tockri]

宣言的UIは「DOMの◯◯を変化させる」っていうコードを1行も書かないから楽だし、引数とフックから得られる変数以外でUIの状態が変化しないから壊れにくいんだよね。

[atsushieno]

imperative vs. declarativeじゃなくてmutable vs. immutable ではないかという気がするけど（imperative UI Fxでも事前に評価式を全て解決してあればモードは生じない）、それがdeclarativeだってことなら異論ではないことになるのかな(?)

[akymrk]

"手続きは前の状態に依存する""手続きは「モード」を発生させる""モードは「モードエラー」を引き起こす""宣言的 UI はモードレス""モードエラーがない = 変更時に壊れにくい"

[rawwell]

ちゃんと理解してないので後で読み直す。関数を並列で動かすときにrace condition が起きなければいいということかな？グローバル変数にlockを取らないで。lock 取ってしまうとデッドロックの可能性ある