Rust で型安全な SPA 開発

Rust.Tokyo 2022 の発表資料です。

https://rust.tokyo/2022

Twitter とか質問を拾って回答したものを最後に追加しています。

以下は、スライド中のリンクです。

p5
- https://speakerdeck.com/koichik/isomorphic-survival-guide?slide=22

p47
- https://github.com/rust-unofficial/awesome-rust#gui
- https://github.com/flosse/rust-web-framework-comparison#frontend-frameworks-wasm

p69
- https://rustwasm.github.io/wasm-bindgen/examples/websockets.html

Transcript

1. Rust で型安全な SPA 開発 Rust.Tokyo 2022 2022-09-23 Fairy Devices Inc. プロダクト開発チーム 名和
2. 目次 1. はじめに 2. 作ったものの紹介 3. The Elm Architecture (TEA) と Rust での実装 4. JS/TS と比べてどうか？ 5. おわり 2
3. 目次 1. はじめに 2. 作ったものの紹介 3. The Elm Architecture (TEA) と Rust での実装 4. JS/TS と比べてどうか？ 5. おわり 3
4. お前誰やねん 最近は Rust を 1 年半ほど書いています。好きな Web バックエンドの crate 構成は axum + sqlx。 また、Vue.js 2.x を 3 年ほど書いていました。C++ も 3 年ほど。 Elm も 3 ヶ月くらい触っています。 4 フロントエンド (外向け) フロントエンド (内部) バックエンド
5. フロントエンドと SPA (Single Page Application) SPA とはクライアント端末上でフロントエンドが動くアプリケーションです。 主に UI の話をするので、以降はフロントエンドと言います。 5 Isomorphic Survival Guide より引用 https://speakerdeck.com/koichik/isomorphic-survival-guide?slide=22
6. なぜ Rust でフロントエンドを作りたいのか • Rust が好き！！！ • Rust は裏方だと思われているが、フロントエンドはどれくらい書けるのか試してみ たい • wasm にコンパイルできるので、ブラウザー上でも意外と動きそう • バックエンド (外部システム) とのデータを serde※ で Rust 内の表現に変換できる。ま た、バックエンドも Rust で書くなら、型定義が共有できそう 6 ※ serde の読み方をよくわかっていませんが発表中は「せるで」に統一します。
7. 目次 1. はじめに 2. 作ったものの紹介 3. The Elm Architecture (TEA) と Rust での実装 4. JS/TS と比べてどうか？ 5. おわり 7
8. 発表したい内容 先程のモチベーションによって、運用ツールのフロントエンドを Rust で書いてみたことで 得られた「知見」についてお話します。 改めて、Rust でフロントエンドを書くことへの期待として以下があります。 • Elm※ と同等な型安全性に守られたフロントエンド開発 • serde で外部システムの JSON データと Rust 内データの変換が容易 • バックエンドと型定義が共有できるかも 8 ※「Elm」については後のスライドで説明します。
9. まずは顧客向けではない運用ツールを作る 顧客向けにいきなり Rust フロントエンドを作るのは厳しいので、社内の IT エンジニアで はない方に使ってもらう運用ツールを作成しました。 作成した 2 個を紹介します。 • Web アプリ: サーバーインスタンス内の DB にアクセスするバックエンドも作りたい ため • デスクトップアプリ: バックエンドがすでに提供している API を呼びたいので、 PC 内で動作するデスクトップアプリ 9
10. 採用した crate 今回 2 つの社内向けツールを作るにあたって、それぞれ異なる crate を採用しました。 • seed-rs: The Elm Architecture と似た形で Web フロントエンドを作成できる • iced: Elm にインスパイアされた Rust 用のマルチプラットフォーム GUI crate であ る 10 https://github.com/seed-rs/seed https://github.com/iced-rs/iced
11. フロントエンド・バックエンド両方を Rust で作成した。 11 seed-rs を使ったツール
12. seed-rs のフロントエンド、actix-web と diesel のバックエンドを持つ Full Rust のツールを作成した。(Materialize CSS でデザイン) SQL の打ち間違いなどのリスクを減らしたい。 • フロントエンド・バックエンドで型定義を共有できた (そもそも seed-rs の examples にある) • デザイン部分を CSS におまかせできた seed-rs を使った場合の知見 12 作成した運用ツール PostgreSQL Java nginx やったこと: 　 　 目的: 　 良かったこと: 　
13. iced を使ったツール 運用用デスクトップアプリを iced で作成した。 13
14. やったこと: 　 目的: 　 良かったこと: 　 • 認証情報の取得の自動化ができた • 取得した情報を見ながら操作できる iced を使った場合の知見 14 ① 認証情報の取得 ② 登録データの取得 ③ ②を見ながら操作 LINKLET (弊社サービス) 運用用デスクトップアプリを iced で作成した。 運用 API をコマンドラインから使うと、手数が多いので楽にしたい。
15. seed-rs・iced の特徴 seed-rs も iced も Elm like に書くことができるため、大きな違いはありません。 強いて挙げるなら Web フロントエンドのみか、マルチプラットフォームかの違いがありま す。 • seed-rs: HTML タグで UI を構成して、wasm にビルドする • iced: UI 部品オブジェクトで UI を構成し、実行可能バイナリーや wasm にビルドす る 15 ※ UI 部品オブジェクト: Text や Row、Column など
16. 目次 1. はじめに 2. 作ったものの紹介 3. The Elm Architecture (TEA) と Rust での実装 4. JS/TS と比べてどうか？ 5. おわり 16
17. Rust と The Elm Architecture (TEA) の相性が良くとても書きやすい Elm は AltJS の 1 種で、The Elm Architecture (TEA) の上でフロントエンドとして動き ます。ただ、Elm は関数型言語であるため慣れていない人はとっつきにくいかも知れま せん。 Rust も強い型であるため、TEA like にフロントエンドを書く crate があります。 17 https://guide.elm-lang.org/architecture/ The Elm Architecture (TEA) Elm TEA like Rust crate
18. The Elm Architecture (TEA) seed-rs と iced の双方とも The Elm Architecture (TEA) を参考にしています。 Model で内部状態を定義し、内部状態をどう表示するかを View として実装し、UI など からの Message を受け取る Update で Model を更新します。 Model 内部状態 View UI 定義 Update 更新処理 Message 18
19. seed-rs: カウンターの実装例 Rust での TEA 上の実装と動作イメージを、seed-rs の最初のサンプルであるカウン ターアプリで説明します。 19 Model 内部状態 View UI 定義 Update 更新処理 Message
20. seed-rs: カウンターの実装例 Model の初期状態を init() で定義する。 fn view(model: &Model) -> Node<Msg> { div![ "Counter: ", button![ model.counter, ev(Ev::Click, |_| Msg::Increment), ], ] } fn update( msg: Msg, model: &mut Model, _: &mut impl Orders<Msg>, ) { match msg { Msg::Increment => model.counter += 1, } } enum Msg { Increment, } struct Model { counter: i32, } fn init( _: Url, _: &mut impl Orders<Msg>, ) -> Model { Model { counter: 0 } } 20 ※ これらを指定してアプリを開始する部分は省略しています
21. seed-rs: カウンターの実装例 Model から view() で UI が作られる。 fn view(model: &Model) -> Node<Msg> { div![ "Counter: ", button![ model.counter, ev(Ev::Click, |_| Msg::Increment), ], ] } fn update( msg: Msg, model: &mut Model, _: &mut impl Orders<Msg>, ) { match msg { Msg::Increment => model.counter += 1, } } enum Msg { Increment, } struct Model { counter: i32, } fn init( _: Url, _: &mut impl Orders<Msg>, ) -> Model { Model { counter: 0 } } 21 ※ これらを指定してアプリを開始する部分は省略しています
22. seed-rs: カウンターの実装例 Model から view() で UI が作られる。 fn view(model: &Model) -> Node<Msg> { div![ "Counter: ", button![ model.counter, ev(Ev::Click, |_| Msg::Increment), ], ] } fn update( msg: Msg, model: &mut Model, _: &mut impl Orders<Msg>, ) { match msg { Msg::Increment => model.counter += 1, } } enum Msg { Increment, } struct Model { counter: i32, } fn init( _: Url, _: &mut impl Orders<Msg>, ) -> Model { Model { counter: 0 } } 22 ※ これらを指定してアプリを開始する部分は省略しています
23. seed-rs: カウンターの実装例 UI 上などでイベントが起こると Message が Update に渡される。 fn view(model: &Model) -> Node<Msg> { div![ "Counter: ", button![ model.counter, ev(Ev::Click, |_| Msg::Increment), ], ] } fn update( msg: Msg, model: &mut Model, _: &mut impl Orders<Msg>, ) { match msg { Msg::Increment => model.counter += 1, } } enum Msg { Increment, } struct Model { counter: i32, } fn init( _: Url, _: &mut impl Orders<Msg>, ) -> Model { Model { counter: 0 } } 23 ※ これらを指定してアプリを開始する部分は省略しています
24. seed-rs: カウンターの実装例 Message に基づいて Model を更新する。 fn view(model: &Model) -> Node<Msg> { div![ "Counter: ", button![ model.counter, ev(Ev::Click, |_| Msg::Increment), ], ] } fn update( msg: Msg, model: &mut Model, _: &mut impl Orders<Msg>, ) { match msg { Msg::Increment => model.counter += 1, } } enum Msg { Increment, } struct Model { counter: i32, } fn init( _: Url, _: &mut impl Orders<Msg>, ) -> Model { Model { counter: 0 } } 24 ※ これらを指定してアプリを開始する部分は省略しています
25. seed-rs: カウンターの実装例 ぐるぐる回る。 fn view(model: &Model) -> Node<Msg> { div![ "Counter: ", button![ model.counter, ev(Ev::Click, |_| Msg::Increment), ], ] } fn update( msg: Msg, model: &mut Model, _: &mut impl Orders<Msg>, ) { match msg { Msg::Increment => model.counter += 1, } } enum Msg { Increment, } struct Model { counter: i32, } fn init( _: Url, _: &mut impl Orders<Msg>, ) -> Model { Model { counter: 0 } } 25 ※ これらを指定してアプリを開始する部分は省略しています
26. enum で列挙して match で網羅できるのが良い① Message・Update の実装で、enum と match が相性が良いです。 例えば「デクリメントボタンを追加」「入力フォーム※から値を指定する」などの機能が増え ることを考えると、 26 enum Msg { Increment, Decrement, // added! Set(i32), // added! } fn update(/* ... */) { match msg { Msg::Increment => model.counter += 1, Msg::Decrement => model.counter -= 1, Msg::Set(val) => model.counter = val, } } ※ 入力フォームがあると、フォームの変更を追うための Message も要りますが省略しています Message・Update の実装で、enum と match が相性が良いです。 例えば「デクリメントボタンを追加」「入力フォーム※から値を指定する」などの機能が増え ることを考えると、 • アクションの追加は Msg 列挙体にただ追加する • Update では match で網羅できていないとコンパイルエラーする
27. enum で列挙して match で網羅できるのが良い② Model・View の実装でも、enum と match が相性が良いです。 例えば「タブビュー」の実装を考えると、Model に enum を持って、View で match して UI 定義を切り替えると実装できます。 27 struct Model { tab: Tabs, } enum Tabs { Home, Counter(i32), } ※ この例だと Counter の値が保存されないので微妙です。実装したツールではタブ切替時にデータ取得しています。 Welcome 0 Counter Tabs::Home Tabs::Counter(0)
28. iced でのカウンターアプリの実装例 seed-rs と比べると、ボタンの状態が追加されたり、UI 定義が変わっています。 impl Counter { fn view(&mut self) -> Row<Msg> { Row::new() .push(Text::new("Counter: ".to_string())) .push(Button::new( &mut self.incr_btn, Text::new(self.value.to_string()) ).on_press(Msg::Increment)) } } impl Counter { fn update(&mut self, msg: Msg) { match msg { Msg::Increment => self.value += 1, } } } enum Msg { Increment, } struct Counter { value: i32, incr_btn: button::State, } impl Counter { fn new() -> Counter { Counter { value: 0, incr_btn: button::State::default(), } } } 28
29. カスタムコンポーネントを作る フロントエンドの実装では、UI 部品をまとめてカスタムコンポーネントを構成することを良 くやります。 iced でページネーション用のコンポーネントを実装する例で説明していきます。 29
30. ページネーションコンポーネントの view() 30 ボタンを共通スタイルにするための補助関数
31. ページネーションコンポーネントの実装 31 親コンポーネント 親コンポーネントにイベ ントを伝える 子コンポーネントの Model を生成
32. ページネーションコンポーネントの実装 32 親コンポーネント 子コンポーネントの Model を生成 親コンポーネントにイベ ントを伝える
33. 余談: Component の型引数が難しい 型変数が多くてうわってなりますが、リポジトリーの examples にあるので、そのまま 持ってきています 33
34. 利用側でコンポーネントの情報を保持して渡す ページネーションコンポーネントでイベントがあると再フェッチする例です。 34 ※ struct PaginationData みたいなのをコンポーネント側から公開すると、フィールド・引数が減らせるが説明のため直接渡す
35. 利用側でコンポーネントの情報を保持して渡す ページネーションコンポーネントでイベントがあると再フェッチする例です。 35 ※ struct PaginationData みたいなのをコンポーネント側から公開すると、フィールド・引数が減らせるが説明のため直接渡す Command::perform() で非同期処理を行い、 結果から Message を作成できる
36. • フロントエンド・バックエンドを同じ Rust で書くことで、型定義を共有できて実装が楽 になる • serde で外部システムからのデータを Rust の表現にできる • enum と match があることで実装しやすい ◦ Rust でも Elm と同等の型安全性が得られる ◦ Rust も Elm 同様プログラム内では、そうそうエラーは起こらない • カスタムコンポーネントのデータを利用側の Model に保持する必要がある Rust・TEA のまとめ 36
37. 目次 1. はじめに 2. 作ったものの紹介 3. The Elm Architecture (TEA) と Rust での実装 4. JS/TS と比べてどうか？ 5. おわり 37
38. JS/TS と比べたメリット・デメリット メリット 1. データ型定義を共有できて開発しやすい - フロントエンドとバックエンドの言語を統一したことによる 2. wasm-bindgen で JS 側と Rust 側のやり取りがやりやすい 3. デスクトップアプリだとファイル操作などをやり慣れた Rust で書ける デメリット 1. プラグインで対応できるものを自作する必要あり 2. ビルド時間が長い 3. Web フロントエンドだと、HTML あたりが冗長だったり CSS の選定が難しかったり する 38
39. バックエンドも一緒に作ると型定義を共有できて便利 Node.js バックエンドで同じことができるが、Rust でもできる • TypeScript はフロントエンドが得意 vs Rust はバックエンドが得意 異なる言語で書くと、どちらを書いているかわかりやすい (DSL) という観点もある • フロントエンド・バックエンドで書き方がだいぶ違うのであまり気にしなくて良いかも 39 JS/TS と比べてどうか？ (1/6)
40. wasm-bindgen で JS 側と Rust 側のやり取りが楽 JS の関数を Rust から呼ぶ 40 JS/TS と比べてどうか？ (2/6) Rust の関数を JS 側に公開 (呼ぶのは seed-rs)
41. プラグインで対応できるものを自作する必要あり 以下のような機能は JS/TS では、パッケージをインストールすれば設定のみでほぼ実 装は不要です。カッコ内は Nuxt.js でのパッケージ名です。 • 認証機構 (@nuxtjs/auth-next) • i18n (@nuxtjs/i18n) • store (vuex) • localStorage へのデータのキャッシュ(vuex-persist) デスクトップアプリであれば、データのキャッシュはファイルに書き出せば※良いので、 Rust で書けることが嬉しいかも 41 ※ Isomorphic Survival Guide の定義ではバックエンドである JS/TS と比べてどうか？ (3/6)
42. ビルドが遅い JS/TS だと開発ビルドでは以下の、開発ビルドの際の支援がある • ビルド中にアクセスできて、ビルド時間を意識しづらい仕組みがあったり • ビルドが終わったら自動的にページがリロードされたり Rust はリンクが遅い • 実行可能バイナリーや wasm が作られるまで、見た目が確認しにくい 42 JS/TS と比べてどうか？ (4/6)
43. HTML 出力の場合はデザインフレームワークに制限あり 以下の制限があります。 • なるべく CSS 単体で動く • JS で DOM の変更をしない Elm も同様ですが、むしろ JS/TS がよくできてる部分です。 次のスライドで詳しく説明します。 43 JS/TS と比べてどうか？ (5/6)
44. 生の HTML を意識するのがつらい JS/TS だと Vuetify や Ant Design のようなデザイン込みのフレームワークがあります。 それらが提供するコンポーネントを使うと以下のようになります。 • それなりのデザインの UI が作成できる • 共通テーマなどで一括でデザインを指定できる 逆に Vue・React に依存しないことがメリットかも知れません。 • しかし React like とか Elm like とかが多いので JS/TS の後追いっぽさはある 44 JS/TS と比べてどうか？ (6/6)
45. 目次 1. はじめに 2. 作ったものの紹介 3. The Elm Architecture (TEA) と Rust での実装 4. JS/TS と比べてどうか？ 5. おわり 45
46. まとめ • Rust でも意外とフロントエンドが作成できる • TEA like で作成できるため、Elm のようにランタイム時に問題はそうそう起こらない • 外部システムのデータのやり取りは serde でほぼ意識せずに行える • デザインがちょっとつらいけど、運用ツールなど機能が大事なものは十分作成でき そう 46
47. おまけ: GUI 関連 crate の紹介 様々な crate があって触ってみたいと思っています。 これまでのスキルセットや目的にあった crate もあるかも知れません。 • React 風に書くことができる crate ◦ Yew: 一番有名？React and Elm like を謳っている。 ◦ Dioxus: rsx!() マクロで React のように書ける。 ◦ and more... • egui: 即時モードという描画方式でゲームエンジンと相性が良いらしい。 • Bevy: ゲームエンジン。もちろん GUI が必要。 • Tauri: Electron の Node.js 部を Rust で実装する。 https://github.com/rust-unofficial/awesome-rust#gui https://github.com/flosse/rust-web-framework-comparison#frontend-frameworks-wasm 47
48. Fairy Devices は Rust.Tokyo 2022 のゴールドスポンサーです この後にスポンサーセッションがあります。チャンネルは閉幕までそのままで！ 48
50. 以下、発表後に追加したスライドです。 質疑応答もけっこうテンパってしまったので、回答を載せています。 Twitter からも拾ってますが、参照されたくないかもしれませんのでリンクのみ。 50
51. sli.do より 1 > JSでフロントエンド書くのが一般的だと思ったんですが、どう会社を説得してRust採用 したのか気になります！ 「まず書いてみた」「それを育てていく」と回答しましたが、そもそも @emergent が Rust 推進派なのでとても通りやすい環境になっています。 51
52. sli.do より 2 > seed-rs, iced 以外に選択肢として上がったcreateはありましたか？ また、あった場合 この2つを選んだ理由が聞きたいです。 Rust のフロントエンド crate は群雄割拠すぎて、自分にとって書きやすいかなと思った らまず書くのが良いと思っています。 なので、seed-rs は Elm like で Elm 経験があり、チュートリアルがわかりやすかったの で採用して書きました。 @emergent が iced を採用したのは書籍で扱っていて、利用したことがあったからだそ うです。 52
53. sli.do より 3 > JSなどと比較すると、まだまだRustでのGUI実装には、十分な機能が不足していると 感じる箇所が多々あるのではないかと思ったのですが、 このあたりがもっと拡張されて いくと、実務・本番でも使えるようになると感じられましたでしょうか？ 一番開発体験が悪かったのはビルド時間です。GUI の機能としては、自作が必要で工 数がちょっと多めになりそうなこと以外は、問題ないと思います。 store も once_cell でグローバル変数みたいな形で実装できそう、とか。 あと、ゲーム用途でパフォーマンスが要るものだと可能性があると思います。 53
54. sli.do より 4 > Yewは試したことありますか？もしそうなら感想聞きたいです 最近ちょっと触る機会があったのですが、アップデートで Hooks が入ったことでほぼ React になったなと思いました。 54
55. sli.do より 5 > 色々cratesあって何を選ぶのが良いのかかわかりません。どう選ぶと良いでしょうか p52 と同じですが、Rust のフロントエンド crate は群雄割拠すぎて、自分にとって書きや すいかなと思ったらまず書くのが良いと思っています。 探すのは p47 にも書いた以下のリンクより。 https://github.com/rust-unofficial/awesome-rust#gui https://github.com/flosse/rust-web-framework-comparison#frontend-frameworks-w asm 55
56. sli.do より 6 > Tauriってのが流行ってるみたいですがどうでしょうか Tauri は Electron のデスクトップ側部分 (バックエンド※) を Rust で実装するようにした ものです。 フロントエンドは Web の技術で実装するのですよね。なので、Tauri の上で React を動 かしたり、たぶん seed-rs を動かしたりできると思います。 56 ※ ほとんどそのまま Isomorphic Survival Guide の p15 の構成ですね……すごい資料だ。 https://speakerdeck.com/koichik/isomorphic-survival-guide?slide=15
57. sli.do より 7 > CSSとかはどこに記載していくことになるのでしょうか？ 今回省略したのですが、HTML ファイルから wasm を読み込むので、そのときに CSS も指定できます。 57
58. sli.do より 8 > 他の言語でのGUI開発でよく使うツールが無くて不便だったことはありますか？JSの StoryBookとかReact Dev Toolとか。本番で使うならそういうのあると良いなあと思いま すがどうでしょう devtools は Elm・Rust では必要になったことがないんですよね。コンパイルが通ったら devtools が必要だったようなバグをほぼ見ないです。 StoryBook はビルドが遅いのでないのがつらい。 58
59. sli.do より 9 > Rustはコンパイル時間が長いのがつらいイメージがありますが、ホットリロードみたい な類のことは出来たりするのでしょうか ホットリロードはできません。つらい。 59
60. sli.do より 10 > バックエンドとの型共有、素晴らしいと思います。protobufとかでやるのと違いはあり ますか？パフォーマンスや開発効率とか。 protobuf を知らなかったのですが、GraphQL や OpenAPI のようにスキーマファースト で書く形っぽいですかね。 型定義の共有自体は、もう Rust しか使わない、みたいな判断になってロックインに繋が るので、初期段階の開発スピードがほしいときだけだと思います。 パフォーマンスは、結局 serde で変換されると思うので変わらないと思います。 60
61. sli.do より 11 > RustでのGUI開発を選択する基準はありますか？こんなプロジェクトならWeb技術の GUIよりRustのGUIが良いとか。 Rust でバックエンドを作成していて、cargo workspace を使っているなら、型定義だけ crate を分けると Cargo.toml で依存を書くと持ってこれて簡単に共有できるので、現在 でも Rust で GUI を作る余地はあるかなと思います。 61
62. sli.do より 12 > seed-rsは最終的にWebAssemblyに変換してブラウザで動かすのでしょうか？ そうです。 62
63. sli.do より 13 > Reactなど普段書いています。それに比べて記述量が多そう。Rustならではのメリッ トってあるのでしょうか 記述量は多くなりますね……※ 第 1 には、Rust だと match でもれなく実装できるというのが嬉しいです。 あとは好みの問題ですが、大域脱出がないことが良いと思っています。(質問と関係ない ですが Rust は GC がないことがとても好き) 63 ※ 個人的には記述量が多い (ボイラープレートが多い ) ことはデメリットだと思っていないです。 (標準的な意見ではないと思う。 ) 記述量が少ないことは、逆に暗黙のルールが多いことを表していて、読むときにその場にない知識が必要になるデメリットだと思います。
64. sli.do より 14 > 作成したページのロード時間はどの程度でしょうか。社内ツールのようなので、あまり 問題にはならないのかもしれませんが、もし測定されていたのであれば教えていただけ ないでしょうか。 ロード時間は気にしていなかったです！参考までにファイルサイズですが、リリースビル ドの wasm は 668 KB でした。 Materialize CSS の JavaScript・CSS がそれぞれ 176 KB・138 KB なので、wasm は まあまあ大きい※ですね。 (iced はローカルで動くので N/A です。画像とかのアセットがないのでローカルまできた らどちらも爆速で動きます。) 64 ※ あまり考えずに crate に依存している部分があるので、ちゃんと整理して詰めれば減らせるとは思います。
65. sli.do より 15 > 本番システムでRustのGUIを採用する上での一番のネックはなんですか 個人的に 1 番ネックなのは、認証まわりの処理を自作する必要があることかなと思いま す。自作するとどうしてもセキュリティ的に正しいのかを確信が持てなくなってしまうので …… 65
66. sli.do より 16 > 規模の大きい開発をする場合、１つのスクリーン(view)で複数のviewModelを用意す るような実装ってseedでできますか？ viewModel がなにを指しているのかあまり理解できてなくてすみませんが、seed-rs で カスタムコンポーネントを作るとか、複数のカスタムコンポーネントでデータを共有すると かでしょうか？ カスタムコンポーネントは作れますが、後者のデータ共有の場合は store みたいなもの を自分で実装する必要があります。 66
67. sli.do より 17 > Viewとそれ以外のロジックが密結合で、長期的にメンテするとき、Viewだけ別ライブラ リに乗り換えたりが大変そうな印象です。良い設計方法やアーキテクチャはあります か？どう調べたら良いでしょうか View だけ別ライブラリーに乗り換えるのは実際大変だと思いますが、JS/TS でも一緒 だと思います。crate の数が多くて、乗り換えしたくなるというのはその通りですが。 ただ Elm like から別の Elm like に乗り換える場合、コンポーネント構成を使い回せる のでコンパイルエラーを地道に直していくと乗り換えできると思います。 67
68. sli.do より 18 > RustでWebのGUI開発、流行るでしょうか？どうお考えですか？ 正直、特に Web はあまり流行るとは思ってないです。デスクトップアプリはまだ余地が あるかなと思います。 なので、拡大していくならデスクトップアプリで GUI 作れるよね→それを wasm でビルド すれば Web でも動くよね→……と言った流れかなと思います。 68
69. sli.do より 19 > Elm で解決できないことは Ports で結局 JavaScript の世界で解決しないといけない ということがありますが、Rust ではそのあたりが変わりますか？ Elm で Ports を使う必要があるのは「Elm の外側にある API を使う」ときだと思います。 Ports のサンプルにもなっている WebSocket とか、外部ライブラリーの関数を使ったり とか。 後者は Rust でもどうしようもないです※が、前者の WebSocket などブラウザー API の 利用には web_sys という crate があって Rust で完結できます。※ https://rustwasm.github.io/wasm-bindgen/examples/websockets.html 69 ※ Rust だと Ports ではなく wasm-bindgen を使った FFI です ※ Elm でも Ports をラップしたパッケージを使えば良いみたいですね
70. Twitter より 1 https://twitter.com/rabe1028/status/1573129864127062017 seed-rs も iced も両方 TEA なのでそこまで書き味に差はないです。 実は Tauri とか Electron とか使えば Web フロントエンドのデスクトップアプリは書ける ので、seed-rs だからブラウザーでしか動かないなんてこともないんですけども。 70
71. Twitter より 2 https://twitter.com/gorilla0513/status/1573130738157096960 Model の変更は常にイベントを契機に update() で受けたいので、view() では不変に なっています 71
72. Twitter より 3 https://twitter.com/seanchas_t/status/1573133330702536705 社内で聞いてみたところ、逆に JS/TS がそれなりに書けるのは私しかいませんでした。 (私もすごい書けるとは言えない……) 72
73. Twitter より 4 https://twitter.com/gorilla0513/status/1573134075124420609 iced は mold でかなり改善できそうな気はします。seed-rs は wasm ですが、mold 対 応してるんでしょうか……？ 73