Effective SwiftUI 候補（仮説）
私が SwiftUI で開発する際に 効果的（Effective） だと感じたプラクティスを記事にしたものです。
元々、Twitter や Zenn のスクラップで書いていたのですが、よりオープンにディスカッションできればと思い、GitHubディスカッションに移行しました（全面的に1からリライトしています）。
どなたもお気軽にリアクション・コメントをいただければと思います。
初めての方は、本ページ下部にある短い FAQ にだけ目を通して頂けると幸いです。
効率的な実装
- プレビュー用に空の SwiftUI プロジェクトを用意する。
- 新規 View / Modifier を作成する際はスニペットを利用する。
- body 関数のコンパイルエラーの内容が理解できない場合、小さな関数に移動して試す。
- 複雑な View を作成する時は「コードの折りたたみ」機能を活用する
- コード補完を活用し、クロージャを素早く記述する。
ドキュメント
コーディングスタイル
- サブビューを生成する処理は Computed-property よりメソッドを好む。
- Button における
actionの指定方法について検討する。 - View の構造を把握しやすくするために目立つコメントを記述する。
API を理解して使用する
- 離れた View にデータを渡す際には
@Environmentや@EnvironmentObjectの利用を検討する。 - 本当に必要な場合を除き AnyView を避ける。
- UIViewRepresentable のプロトコル要件を正しく理解して使う。
- シートを実装する際は isPresented と dismiss を利用する。
- AppStorage で不足な場合は Defaults の利用を検討する。
- 標準以外の方法でローカライズを処理する際のデメリットを理解する。
- View を拡張したい場合は原則として extension を使用し、状態保持が必要な場合のみ
ViewModifierを実装する。 - 複数の要素に同一の Modifier を適用する際は
Groupの利用を検討する。
トレードオフ
マルチプラットフォーム
テクニック・アイディア集
- 可読性のための Modifier を導入する。
- .tag() を enum などで指定する場合、型付けされた専用のメソッドを用意する。
- 必要な場合は
Binding<T>をBinding<T?>に変換する。 - View の更新トリガーを調べるために
_printChanges()を利用する。 - 上位互換 API を自前で実装し、OSアップデート時のコストを低減する。
- デバッグ目的の Modifier / View の実装を検討する。
未成熟な仮説（私の中で答えが出ていないもの）
- ViewModel で非同期通信が必要な場合、
@MainActorで宣言する。 - NavigationView は常に利用する側の View で指定する。
@ObservedObjectへの DI をonAppearで決して行わない。- 初期化のために一度だけ実行する処理は
lazy varで行う。
FAQ
Q. なんだか文体が偉そう...
A. Effective本を意識して書き始めたら、このような文体になってしまいました...合わない方には申し訳ないです。
Q. 記事リンクを単発でシェアしてもいい？
A. はい、大丈夫です。
Q. 書籍化する予定は？
A. 検討中です。ただ有料の書籍として販売した場合も、ここをクローズするつもりはありません。
Q. あなたは SwiftUI で何を作ったの？
A.
- Multi-platform アプリとしては：
- ライブラリとしては：
Author
Yusuke Hosonuma / @tobi462