【JavaScript】ここがしんどかったよTauri開発【Rust】 #JavaScript

2024年2月2日にTauri 2.0がβ版となりました。昨年から個人的にいくつかTauriの1系でデスクトップアプリケーションを開発してきたのですが、ここが辛かった！というのを列挙してみました。

因みに公開しているのは以下となります。

尚、Iron Beads Editor(以下IBE)に関しては元々Vanilla.jsでweb側を作っていて、それの機能追加版となります。

なぜTauriを選択したのか？

まずTauriを選択する前に以下のプラットフォームを検討しました。

Platform	所感とか
Electron	The 王道！Chromiumを同時にインストールさせる、ノウハウ沢山しかし、バイナリがでかい
gluon	各配布先のユーザーのnode.jsを使うので非エンジニアに対してハードル高杉FireFox対応してるDenoやBunが使える（だから何？）
Tauri	Rust製…今回の記事
neutralino	インドの人が開発。DBが貧弱と言われるがjsonで管理できるものなら問題ない感じ

ElectronはLinux用のGUIツールが必要だった際にやったことあったので、neutralinoとTauriで同時に開発していったのですがドキュメントの見やすさでTauriに軍配が上がりました。
それでも色々ひっかかりました。以下は本題のひっかかり所です。

JS側のサンプルは充実しているのにRust側のExampleが貧弱

多分、Tauri側のコンセプトがRustを最低限書けばあとはJSを書くだけで動くというのがあるのでしょうが明らかにRust側のサンプルが少なすぎるんですね。
例えば、windowのタイトルを動的に変更したい場合JS側はsetTitleにきちんとサンプルがありますが、Rust側のset_titleには最低限の記述しかありません。

ググると必ずJS側のサンプルばかりがhitして「Rust側でどうやって実装するんだっけ？」みたいな時に何度か迷子になっていました。（そもそもmethodが存在するか？のチェックを何度もしていたので迷子になった）
開発効率を考えるとRust側の方のdocsにもExampleがあった方が親切だと思いました。

WRYに引きづられる

当たり前のことですが結構重要だったので記述します。
TauriはWebViewの部分をWRY(WebView Rendering Library）を使っています。(Servoの様な代替のものも検討されていますが、多くはWRYを使っていると思っています)

「何が言いたいか？」というとChromeとか最新ブラウザで動くものをTauriに移植しようとしてもWRYで対応していないタグやCSSがあって動かないということです。

実際にIBEのweb版ではdialogタグを使っていたのですが、WRYでは対応してませんでした。

<dialog>ダイアログの内容</dialog>

他にもdomの画像化に対してhtml2canvasを使っていたのですが、cssのcounter-increment部分が上手くできなくてhtmlToImageで無理やり実装しました。

release版だけ起こる謎のバグ

前述したWRYの対応していないタグに似ていますが、JSでHTMLのinput type="color"の値を動的に変更しようとするとdev版では何も問題ないのにBuildしてrelease版を使うとWRY部分だけ再起動してしまう謎のバグがありました。(ログにも出ない)

[2024/02/15追記]
思い出したことがあったので追記します。
日本語と英語対応しようと思っていた時に戻り値違いがあってdevだと「ja-JP」でbuildすると「en-JP」になることもありました。

#[tauri::command]
fn is_japanese() -> bool {
    let current_locale = current_locale::current_locale();
    let current_lang = current_locale.ok().unwrap();
    //println!("current_lang: {}", current_lang);
    //devだと「ja-JP」buildだと「en-JP」が戻り値になる
    if current_lang.ends_with("JP") {
      return true;
    }
    return false;
}

[追記ここまで]

Mac/Windowでクレートの挙動が違う…

String Scouterでは自分の拘りもあって変わったUIにしました。
で、やっぱり透過をしたら影をつけたくなるのでwindow-shadowsをやったところWindowsで以下のようになりました。(四角のWindowにしか対応してない…)

また、所謂send keyとしてenigoを使いましたが、Macでは「Key::Layout('c')」で落ちました。
で、仕方なくrawを使うことで対応できたんですが、今度はWindowsだと動かなくて…

if cfg!(target_os = "macos") {
    enigo.key_down(Key::Meta);
    enigo.key_click(Key::Raw(8));
    enigo.key_up(Key::Meta);
} else {
    enigo.key_down(Key::Control);
    enigo.key_click(Key::Layout('c'));
    enigo.key_up(Key::Control);
}

みたいな処理で対応しました。

OSで挙動が違う

まぁ、クレートなら仕方ないと思いますがこっちはTauriそのものです。
String Scouterでは必要な時にアプリケーションのWindowをActive状態(focusをする)にしていたのですが、Macだとhideして状態のwindowをshowしていなくてもset_focusすればActiveになるんですが、Windowsだと絶対にhideしたものはshowしなければダメでした。

let window = app.get_window("main").unwrap();
window.hide().unwrap();
//↑の状態で↓のmethodを叩くとMacはActiveになるがWindowsはダメ
window.set_focus().unwrap();
//ちゃんとhideしたらshowしましょう
window.show().unwrap();

menuに対するselectedをチェックするメソッドがない(文字列をチェックするのもない)

以下のようなメニューがあった際、通常ならば「チェックの有無」でToggleすると思うのですが、「set_selected(true)」はあるのに「get」がなくて、これを不整合なくやるには一々flagで管理するか何らかのstorageなどに保存していくことになるので面倒でした。

(個人的には色々検討した結果Toggleにはしなかったのですが、クレートを使わずに対応する場合だとlocalstorageに入れるなどでしょうか？)

AIが使えない（GeminiもChat GPTも架空のmethodを教えてくる）

Chat GPTに関しては情報が古めなこともあり仕方ない部分もありますが、Gemini(旧Bard)も存在しないmethodをガンガンおすすめしてきて（前述したset_selectedのget版とか）当たり前ですが、こういうあまり需要がなかったりニッチなものはAIも役に立たないなぁと思いました。

存在しないクレートをおすすめしたりするのは本当勘弁して欲しかったです。

尚、精度としてはGeminiの方がリファクタリングも含めて圧倒的でした。

それでもTauriは楽だ！

もっとひっかかり所はあったのですが、印象的なものを記述しました。
まぁ、String ScouterのようなものならばAutoHotkeyなどでサクッと作れますが、GUIにこだわったりOSを超えてとなると微妙です。(特に昨今同じOSでもCPUがIntelとArm系が混じっていたりしますし)

Tauriはマルチプラットフォームなのに出てくる記事がMacのみだったりWindowsのみだったり複数のOSでbuildした記事があまりなく四苦八苦しました。
Tauriは複数OSのバイナリも「Github Actionsがあれば楽勝！」みたいなのも見かけたのですが、ちゃんと実機である程度buildできる状態にしてからでないとCIに任せられないのはElectronでもGoでもなんでも一緒なのと、もうちょっとマルチプラットフォームでのBuildの記事やノウハウが広がるといいなと、version2.0に期待しています。

とは言え、Electronと比較してバイナリサイズの小ささやRustの恩恵を得られますし、QtやGTKでは表現し辛いGUIもGLなんかを書かずにCSSでサクっと作れるのは凄く恩恵があると思います。
個人的にはServoに期待して今後も使っていこうと思いました。