【Swift】プロトコル と 型 の難しさを Array のextension 化で感じた初心者

以前、so でみつけたこういうコード。


extension Array where Element: Collection { 
  func toD1() -> [Element.Element] {
    return self.flatMap { $0 } 
  }
}

👉 【 Swift 】2次元配列と1次元配列の相互変換 🤔 hatena-bookmark

なんとなく「Collection」 の部分が気持ち悪かったのであれこれやってみます。

 

■ お題

2次元配列を平坦化します。


let data = [
  ["あ", "い", "う"],
  ["え", "お"]
]

print(data.flatMap { $0 })
// ["あ", "い", "う", "え", "お"]

print(Array(data.joined()))
// ["あ", "い", "う", "え", "お"]

これを extension 化しようとして、


extension Array {
  var flattened: [String] {
    flatMap { $0 }
  }
}


Instance method 'flatMap' requires that 'Element' conform to 'Sequence'

とエラーがでるとこからスタートです。

 

■ やってみた

ドキュメントや先人の記事を読んでおきます。

👉 Element | Apple Developer Documentation hatena-bookmark
👉 Array | Apple Developer Documentation hatena-bookmark
👉 [Swift]Array型 #Swift - Qiita hatena-bookmark

型や制約の記述を確認しながら進みます。


extension Array where Element == Array<String> {
  var flattened: [String] {
    // Array(joined()) // Cannot convert return expression of type 'Array<Array<String>>' to return type '[String]'
    // joined().map { $0 } // OK
    // Array<String>(joined()) // OK
    // [Element.Element](joined()) // OK
    // [String](joined()) // OK
    flatMap { $0 } // OK
}


extension [[String]] where Element == [String] {
  var flattened: [String] {
    flatMap { $0 }
  }
}

// ["あ", "い", "う", "え", "お"]


extension Array where Element == [String], Element.Element == String {
  var flattened: [Element.Element] {
    flatMap { $0 }
  }
}

// ["あ", "い", "う", "え", "お"]

ここで、制約を先祖のプロトコルのみにします。


extension Array where Element: Collection {
  var flattened: [Element.Element] {
    flatMap { $0 }
  }
}

// ["あ", "い", "う", "え", "お"]

揃えたほうが良さげです。


extension Collection where Element: Collection {
  var flattened: [Element.Element] {
    flatMap { $0 }
  }
}

// ["あ", "い", "う", "え", "お"]

スッキリしました !

Sequence でもいけるんですね。


extension Sequence where Element: Sequence  {
  var flattened: [Element.Element] {
    flatMap { $0 }
  }
}

// ["あ", "い", "う", "え", "お"]

👉 誰もが知りたいSequenceとCollectionのすべて hatena-bookmark

ちなみに、元の配列に nil を混ぜると、


let data = [
  ["あ", nil, "う"],
  ["え", "お"]
]

上手に処理してくれてますね!


// [Optional("あ"), nil, Optional("う"), Optional("え"), Optional("お")]

 

■ まとめ

プロトコルと型。

よく分かってませんが

なんだか深そうです。

そういえば、どこかに書いてました、

プロトコルを使用することによって得られる柔軟性と、特定の型のメソッドの作成の容易さのバランス

というようなフレーズ。

ありがとうございます。

どこか継承グラフみれるとことかあるのでしょうか ? 独自に書き出さずに。

👉 Dash for macOS - API Documentation Browser, Snippet Manager - Kapeli hatena-bookmark
👉 realm/jazzy: Soulful docs for Swift & Objective-C hatena-bookmark


【SwiftUI】カスタム ViewModifier の使い方と使いどころ 🤔

あまり使ってないので上手に使いたい。

なんとなく使ってる感じなのではっきりさせておきたい。

 

🤔 ViewModifier - 公式ドキュメント

公式ドキュメントをきちんと読んでみます。

To create consistent views, you might reuse the same view modifier or group of modifiers repeatedly across your views.

一貫したビューを作成するために、同じ ViewModifier、または、それのグループを View で繰り返し再利用することができます。

A modifier that you apply to a view or another view modifier, producing a different version of the original value.

View または別の ViewModifier に適用する Modifier で、元の異なるバージョンを生成します。


struct CaptionTextFormat: ViewModifier {
  func body(content: Content) -> some View {
    content
      .font(.caption)
      .foregroundColor(.secondary)
  }
}

Text("Some additional information...")
  .modifier(CaptionTextFormat())

To make your custom view modifier conveniently accessible, extend the View protocol with a function that applies your modifier

カスタム ViewModifier を便利にアクセスできるようにするには、カスタム View Modefier を適用する関数を使用して View プロトコルを拡張します。


extension View {
  func captionTextFormat() -> some View {
    modifier(CaptionTextFormat())
  }
}

Text("Some additional information...")
  .captionTextFormat()

👉 ViewModifier | Apple Developer Documentation hatena-bookmark
👉 Reducing view modifier maintenance | Apple Developer Documentation hatena-bookmark

「一貫性のため」か。

確かに新規作成も変更も面倒ですよね。

 

🤔 Custom ViewModifier vs View extension

@State が必要かどうか。

ViewModifier let you have @State variables, but View extensions do not.

ViewModifier では @State が持てるが、View extension では持てない。

👉 ios - Difference between creating ViewModifier and View extension in SwiftUI - Stack Overflow hatena-bookmark

View を拡張したい場合は原則として extension を使用し、状態保持が必要な場合のみ `ViewModifier` を実装する。

👉YusukeHosonuma/Effective-SwiftUI · Discussion #31 hatena-bookmark

また、

以下、WWDC 2022 SwiftUI Q&A での話のようです。

What’s the difference between a custom ViewModifier vs View extension

Q: What’s the difference between a custom ViewModifier (without DynamicProperty) that uses some built-in modifiers in body(content:), and a custom View extension func that just use those built-in modifiers?

Similarly, what’s the difference between a custom ViewModifier with some DynamicProperty and a custom View with some DynamicProperty (also has a @ViewBuilder content property to receive content to modify) ?

I think two have the same render result and behavior.

A: Because of the way a ViewModifier is expressed, the engine knows it’s not changing the content passed in and can apply performance optimizations (compared to just an extension on View)

カスタム ViewModifier と View extension の違いは何ですか ?

質問:
body(content:) でいくつかの組み込み modifier を使用するカスタム ViewModifier (DynamicPropertyなし)と、それらの組み込み Modifier を使用するカスタム View extension の違いは何ですか?

同様に、いくつかの DynamicProperty を持つカスタム ViewModifier と、いくつかの DynamicProperty を持つカスタム View の違いは何ですか ? (modify する content を受け取るための @ViewBuilder content property もあります)

2つは同じレンダリング結果と動作を持っていると思います。

回答:
ViewModifier の表現方法により、エンジンは渡されたコンテンツを変更していないことを知っており、パフォーマンスの最適化を適用できます。Viewの単なる拡張と比較すると。

👉 WWDC22 SwiftUI Q&A | Swift Discovery hatena-bookmark
👉 https://wwdc22.slack.com/ - Apple Events ​に⁠サ⁠イ⁠ン⁠イ⁠ン⁠す⁠る​ | Slack 

「一度 ViewModifier に切り出すとパフォーマンスが最適化される。」

ということのようです。

一発で View extension にしたほうが間違いなく見通しは良いので、

適正化でどれくらいパフォーマンスが変わるか知りたいところです。

ここで、上の質問で挙げられている4つのパターンのコードを想像してみます。


// body(content:) でいくつかの組み込み Modifier を使用する
// カスタムViewModifier (DynamicPropertyなし)

struct CustomViewModifier: ViewModifier {
  var body(content: Content) -> some View {
    // use built-in modifier
  }
}


// それらの組み込み Modifier を使用する
// カスタム View extension

extension View {
  func customModifier() -> some View {
    modifier(CustomViewModifier())
  }
}


// いくつかの DynamicProperty を持つ
// カスタム ViewModifier

struct CustomViewModifier: ViewModifier {
   @State var state: State = .loading

   var body(content: Content) -> some View {
    // use built-in modifier
  }
}


// いくつかの DynamicProperty を持つカスタム View
// modify する content を受け取るための
// @ViewBuilder content property

struct CustomView<Content: View>: View {
  @State var state: State = .loading
  @ViewBuilder var content: Content

  var body: some View {
    // use built-in modifier
  }
}

この質問者の人、さらっと聞いてるように見えますが、

結構ナイスな質問です。

初心者的には、カスタム View が自然に見えますが。

考えさせられます。

 

🤔 公式サンプルコード

続いて、WWDC2023 のサンプルコードを見てみます。


private struct BackyardViewportContentModifier: ViewModifier {
  var value: BackyardViewportContent
    
  func body(content: Content) -> some View {
    content.layoutValue(key: BackyardViewportContentKey.self, value: value)
  }
}

fileprivate extension View {
  func backyardViewportContent(_ value: BackyardViewportContent) -> some View {
    modifier(BackyardViewportContentModifier(value: value))
  }
}


struct GenerateDataViewModifier: ViewModifier {
  @Environment(\.modelContext) private var modelContext
    
  func body(content: Content) -> some View {
    content.onAppear {
      DataGeneration.generateAllData(modelContext: modelContext)
    }
  }
}

fileprivate extension View {
  func generateData() -> some View {
    modifier(GenerateDataViewModifier())
  }
}

👉 apple/sample-backyard-birds hatena-bookmark

ここでは、カスタム ViewModifier の利用のほとんどが、

「データコンテナ」と「通信API」処理まわりです。

これは #Preview でも使いやすいし、定型のパターン。

👉 【 #SwiftData 】ModelContainer の View へのセット hatena-bookmark

 

🤔 まとめ

やっぱ、View で切り出したくなるのですが。

[参考]
👉 ViewBuilderやViewModifierでSwiftUIのViewを分割する|TAAT hatena-bookmark


【SwiftUI】Environment の考え方

まず、作ってみます。

定型です。


private struct MyEnvironmentKey: EnvironmentKey {
  static let defaultValue: String = "Default"
}

extension EnvironmentValues {
  var myCustomValue: String {
    get { self[MyEnvironmentKey.self] }
    set { self[MyEnvironmentKey.self] = newValue }
  }
}

extension View {
  func myCustomValue(_ myCustomValue: String) -> some View {
    environment(\.myCustomValue, myCustomValue)
  }
}

デフォルトに "Default" という文字列を設定していますが、

SwiftUI の View であればどこでもプロパティラッパーを経由して利用できます。

入れ子になった View で使ってみます。


struct Root: View {
  var body: some View {
    First()
    Second()
  }
}

struct First: View {
  @Environment(\.myCustomValue) var myCustomValue

  var body: some View {
    Text("First " + myCustomValue)
  }
}

struct Second: View {
  @Environment(\.myCustomValue) var myCustomValue

  var body: some View {
    Text("Secound " + myCustomValue)
    Third()
  }
}

struct Third: View {
  @Environment(\.myCustomValue) var myCustomValue

  var body: some View {
    Text("Third " + myCustomValue)
  }
}

「Scound」とか www

続いて、デフォルトの値を上書きして変更します。

Environment の値の変更時には、View のツリー構造を思い浮かべながら影響範囲を考えます。

変更箇所は一行追加のみです。

Enviroment 定義時に extension も作成していますので、それを使っても等価です。


struct Root: View {
  var body: some View {
    First()
    Second()
      .environment(\.myCustomValue, "Another")  // *
      //.myCustomValue("Another") // * extension
  }
}

struct First: View {
  @Environment(\.myCustomValue) var myCustomValue

  var body: some View {
    Text("First " + myCustomValue)
  }
}

struct Second: View {
  @Environment(\.myCustomValue) var myCustomValue

  var body: some View {
    Text("Secound " + myCustomValue)
    Third()
  }
}

struct Third: View {
  @Environment(\.myCustomValue) var myCustomValue

  var body: some View {
    Text("Third " + myCustomValue)
  }
}

Second() に付けた .environment() で更新しています。

影響範囲は「その下位の View すべて」となります。

SwiftUI には、あらかじめ用意された便利な Environment がたくさんあります。

その中から、さらに、加えて font を使ってみます。


var font: Font?
The default font of this environment.

👉 EnvironmentValues | Apple Developer Documentation hatena-bookmark

定義 (extension を含む) の記述は不要なので

ツリー構造だけ気にしながら、

好きなところですばやく上書きしていくことができます。


struct Root: View {

  var body: some View {
    First()
      .environment(\.font, .caption) // *
      //.font(.caption) // * extension
    Second()
      .environment(\.myCustomValue, "Another")
      //.myCustomValue("Another")
      .font(.largeTitle) // * extension
  }
}

struct First: View {
  @Environment(\.myCustomValue) var myCustomValue
  var body: some View {
    Text("First " + myCustomValue)
  }
}

struct Second: View {
  @Environment(\.myCustomValue) var myCustomValue
  var body: some View {
    Text("Secound " + myCustomValue)
    Third()
  }
}

struct Third: View {
  @Environment(\.myCustomValue) var myCustomValue
  var body: some View {
    Text("Third " + myCustomValue)
      .font(.caption) // * extension
  }
}

プロパティラッパー @Environment の利用は不要で、

下位 View に適用されていきます。

さらに、それを上書きもできます。

しかし、「Scound」とか恥ずいわ。

 

🌝 まとめ

ある程度調べてからやってみたのですが、少しイメージと違いました。

- デフォルト値はプロパティとしてどの View でも取得できる。

- 値の変更時に範囲を考慮しながら上書きする。

- プロパティで取得しなくてもそのまま適用されるものもある。

ちなみに、GitHub で調べてみると一番使われてる Built-in EnvironmentValue は、


@Environment(\.dismiss) var dismiss

でした。タイプは DismissAction です。

👉 Environment | Apple Developer Documentation hatena-bookmark
👉 EnvironmentValues | Apple Developer Documentation hatena-bookmark
👉 EnvironmentKey | Apple Developer Documentation hatena-bookmark