PR

Tauri v2で「名前を付けて保存」を実装する前に知っておきたいこと。saveダイアログ、権限、上書き確認の整理

tauri v2 dialog tauri
記事内に広告が含まれています。
スポンサーリンク

こんにちは。Tauriでデスクトップアプリを作っていると、ファイルを「開く」機能の次くらいに欲しくなるのが、保存機能です。特に、画像変換やテキスト出力、設定のエクスポートのような処理では、最後に「どこへ保存するか」を気持ちよく選んでもらえるかが、使い勝手を大きく左右します。

今回は、Tauri v2で「名前を付けて保存」系の導線を作る前に、先に整理しておくと楽になるポイントをまとめます。コードを丸ごと貼るというより、imasupのような「ファイルを生成して保存する」アプリを作るときに、実装前の設計メモとして読める内容に寄せます。

まず押さえたいのは、saveダイアログと実際の書き込みは別物ということ

Tauri v2では、保存先を選ぶダイアログは @tauri-apps/plugin-dialog の save で扱えます。一見これで保存まで完了しそうに見えるのですが、実際には保存先のパスを選んでもらう段階と、そのパスへ書き込む段階は別です。

この切り分けを最初に理解しておくと、設計がかなり安定します。

  • ダイアログ：ユーザーに保存先とファイル名を選んでもらう
  • ファイル操作：選ばれたパスに対して、実際に書き込む

つまり、saveダイアログが返してくれた値をそのまま「保存成功」と見なすのではなく、その後の書き込み処理とエラー処理まで含めて一連の保存体験として設計する必要があります。

キャンセル時の扱いは、先に決めておくと迷いにくい

保存ダイアログは、ユーザーが閉じる可能性があります。このとき返ってくる値が null 相当になるケースを、早い段階で前提にしておくのがおすすめです。

ここで無理にエラー扱いすると、使う側からすると少し怖いUIになります。保存をやめたのは失敗ではなく、ユーザーが操作を中止しただけだからです。実装としては、

  1. save の結果が空なら何もしない
  2. 通知を出すとしても「キャンセルしました」程度に留める
  3. ログではエラーではなく情報として扱う

くらいの温度感が、体験として自然なことが多いです。

Tauri v2では「権限」と「スコープ」を見ないと保存は完結しない

ここが、Webアプリ感覚のままだとつまずきやすいところです。Tauri v2では、ダイアログを出すにも、ファイルへ書き込むにも、capabilitiesで明示的に許可する考え方があります。

たとえば、saveダイアログを使うなら dialog:allow-save、書き込み系のAPIを使うなら fs 側の権限とスコープを確認する必要があります。特に fs は、「どこにでも自由に書ける」前提ではなく、どのパスに対して何を許可するかを絞る設計です。

この方針は最初こそ少し面倒ですが、後から見るとかなり安心です。保存機能は便利な反面、誤ったパス操作や予期しない上書きの入口にもなりやすいので、最初から狭く許可するほうが長く保守しやすいです。

上書き確認は「技術」より「安心感」で考える

保存機能で意外と大事なのが、上書き時のふるまいです。既存ファイルへそのまま書くのか、一度別名で逃がすのか、確認ダイアログを挟むのか。このあたりは実装都合だけで決めず、そのアプリで失うと困るものは何かから逆算すると決めやすいです。

たとえば、再生成が簡単な一時ファイルなら、ある程度シンプルでも問題ないかもしれません。一方で、ユーザーが時間をかけて整えた出力物なら、確認を挟んだり、一時ファイルへ書いてから置き換えたりしたほうが安心です。

個人的には、保存機能は「速い」ことよりも、怖くないことのほうが満足度に効きやすいと感じます。特にデスクトップアプリは、ファイルを直接触るぶんだけ、ユーザーが抱く不安も大きいからです。

まとめ：保存機能は、最後の一歩ではなく体験の中心

Tauri v2で保存機能を作るときは、saveダイアログの使い方だけでなく、キャンセル時の扱い、権限、スコープ、上書き時の安心感までをひとまとまりで考えると、かなり実装しやすくなります。

もしこれから保存導線を入れるなら、まずは「どこに保存させたいか」よりも、ユーザーにどんな気持ちで保存ボタンを押してほしいかを先に決めてみるのがおすすめです。その答えが見えてくると、必要な権限やUIの形も自然に絞れてきます。

参考（本記事で参照・確認した情報）

スポンサーリンク

コメント

タイトルとURLをコピーしました