1. リアルタイム反映させている#

一つ目の発生条件は、削除しようとしているクラスに対してobserveで SwiftUI に再レンダリングをかけているということです。再レンダリング処理をしていなければ当該の問題は発生しませんが、そうするとレコードを追加しても SwiftUI 側に反映されないので、再レンダリング処理をしていない人はいないと思います。

::: tip 再レンダリングについて

SwiftUI は構造体を使っているため、プロパティが変化したことを SwiftUI フレームワークに伝えて画面を再レンダリングするための仕組みがあります。

:::

それが@Stateや@Bindingや@ObservedObjectにおける@Publishedになるのですが、これをそのまま Realm でやろうとすると失敗します。

というのも@Publishedはインスタンスの値自体が変わったタイミングでしか通知がこないので、インスタンスの内部状態が変わってもその変更を受け取れないためです。

そこでobserve メソッドを利用して、Realm のデータベースに変更が起きる度にクロージャ内の処理を実行し、クロージャ内で@Publishedの値を変更すれば、

Realm -> observe -> Closure -> @Published -> SwiftUIという流れで再レンダリングがかかります。

これらの仕様についてはこちらの記事が大変参考になりました。

import Combine

class Dogs: ObservableObject {
    private(set) var dogs = realm.objects(Dog.self)
    private var token: NotificationToken?

    init() {
        token = realm.objects(Dog.self).observe { [self] _ in
            self.objectWillChange.send()
        }
    }

    deinit {
        token?.invalidate()
    }
}

例えば、常に最新のRealmSwift.Results<Dog>を持ちたい場合には次のようなObservableObjectを継承したクラスを定義します。

これはdogsが常に最新のRealmSwift.Results<Dog>を持っているにも関わらず、View が再レンダリングされないことを防ぐため、Realm のDogのデータベースに何らかの変更があった場合にself.objectWillChange.send()で SwiftUI に再レンダリングを促すためのコードです。

dogs自体は最新のデータを持っているので、再レンダリングがかかれば望んでいるデータが手に入るというわけですね。

::: tip 再レンダリングのタイミング

コードを読めばわかるのだがNotificationTokenはrealm.objects(Dog.self)から発行されている。つまりrealm.obbjects(Dog.self)のレコードが変更されたときにしかこのクロージャは呼び出されない。

:::

再レンダリングの不思議#

ここで以下のDogクラスを管轄するDogsクラスとPersonクラスを管轄するPersonsクラスを考える。

なお、DogとPersonは以下の定義を用い、今回はお互いが完全に独立したものとして扱う。

// Realm.swift
import Foundation
import RealmSwift

class Dog: Object {
    dynamic var name = ""
    dynamic var age = 0
}

class Person: Object {
    dynamic var name = ""
    dynamic var gender = ""
}

// RealmModel.swift
import Foundation
import RealmSwift
import Combine

class Dogs: ObservableObject {
    var objectWillChange: ObservableObjectPublisher = .init()
    private(set) var dogs = realm.objects(Dog.self)
    private var token: NotificationToken?

    init() {
        token = realm.objects(Dog.self).observe { [self] _ in
            // 何もしない
        }
    }

    deinit {
        token?.invalidate()
    }
}

class Persons: ObservableObject {
    var objectWillChange: ObservableObjectPublisher = .init()
    private(set) var persons = realm.objects(Person.self)
    private var token: NotificationToken?

    init() {
        token = realm.objects(Person.self).observe { [self] _ in
            self.objectWillChange.send()
        }
    }

    deinit {
        token?.invalidate()
    }
}

これはやればわかると思うのだが、Dogにデータを追加してもビューは再レンダリングされず、Personにデータを追加したときにだけ再レンダリングがかかる。これは実際、そのように動作する。

::: tip 勘違いしやすい点

ここで勘違いされやすいのはDogsはいつまで経っても更新されないと思ってしまうことである。

それは誤りで、データベースが更新される度にPersonsクラスは絶えず更新されている。ただ、その更新が行われたということを SwiftUI が検知できず、ビューが再レンダリングされていないだけなのである。

つまりPerson -> Dogという順でデータを更新された場合には最初のPersonの更新の時点までしかビューが再レンダリングされないが、Dog -> Personの順でデータを更新した場合にはDogは正しく最新の情報が表示されるのである。

:::

リンクを張ってみる#

では次に、Realm.swift だけ更新し、Person -> Dogへの多対一のリンク(List)を持つようにする。

// Realm.swift
import Foundation
import RealmSwift

class Dog: Object {
    dynamic var name = ""
    dynamic var age = 0
    let owner = LinkingObjects(fromType: Person.self, property: "dogs") // 追加
}

class Person: Object {
    dynamic var name = ""
    dynamic var gender = ""
    let dogs = RealmSwift.List<Dog>() // 順リンクを追加
}

すると先ほどと同じで、やはり Dog が更新されたタイミングでしか再レンダリングはかからない。

これ自体に特別な意味はないのだが、Dog クラスと Person クラスにこのような関係性がある場合「Dog だけを追加する」というような状態がないのがわかるだろうか？

例えば Bob が新たに Wataru という犬を飼いはじめ、それをデータベースに入力する場合を考えよう。このとき、単純に Wataru という犬のレコードを Dog クラスに追加するのは意味がない。何故なら、Dog クラスには「誰が飼い主であるか」という情報をプロパティではなくバックリンクでしか持っていないためである。

もしも単純にDogクラスに追加した場合には次のようにPersonクラスのdogsの配列が更新されないため、Wataru のバックリンクを参照したときにnilが返ってきてしまう。

これを防ぐためには「Bob のdogsプロパティに Wataru を追加する」という処理を行わねばならない。つまり、バックリンクを持つデータベースにデータが「追加」されるのであれば、それは「バックリンク先だけで再レンダリング処理考えれば良い」ということになる。

::: tip Realm の挙動について

今回のようにPerson -> Dogのリレーションがある場合、Personにデータを追加する際は必ず「子（Dog）」->「親（Person）」の順でデータベースの更新がかかるので、Personクラスの変更だけをチェックするような仕組みにすれば良い。

:::

データ更新#

なので「追加」という観点から見ればバックリンクを持つデータベースには再レンダリング処理を記述しなくていいことになるが、今回のケースでは実はDogクラスにも再レンダリングのコードを書かなければいけない。

というのも、再レンダリングが必要になるのは何も「データ追加」だけではなく「データ更新」の場合にも必要になるからである。

例えば、飼い犬の名前を変えたい場合などは別にPersonクラスのデータは一切更新しない。こういう場合はPersonのデータが変わっただけで再レンダリング処理をしていると飼い犬の名前が変更されたときに SwiftUI が再レンダリングをかけることができない。

2. プライマリキーを設定している#

二つ目の条件は削除しようとしているデータベースにプライマリキーが設定されているということです。

class Dog: Object {
    dynamic var name = ""
    dynamic var age = 0
    let owner = LinkingObjects(fromType: Person.self, property: "dogs")

    // 追加
    override static func primaryKey() -> String? {
        return "name"
    }
}

このように飼い犬の名前が重複しないように（名前は重複しやすいので、名前にプライマリキーをつけることは基本的にありませんが）プライマリキーを設定すると削除時にクラッシュします。

NavigationView の場合#

NavigationView の場合はobjectWillChangeを指定しなくてもNavigationLinkで遷移するとForEachの中身が自動で再レンダリングされるようだ。

ただし、ForEach以外は再レンダリングされないのでobjectWillChangeを使わなくても良いということではない。

「追加」は問題ないが「削除」をForEachと同じビューで実行してはいけない。

::: tip 削除と同じビューとは

From {
    Button(action: { deleteAll() }, label: { Text("DELETE") }) // dogsのレコードを削除する
    ForEach(dogs) { dog in
        Text(dog.name) // ForEachなのでwillObjectChangeがなくても更新される
    }
    Text("\(dogs.count)") // ForEachでないので更新されない
}

のように dogs(RealmSwift.Results)自体を弄るような関数を同じビューに書いてはいけないということを意味する。

:::

その場合、プライマリキーがあればInvalidateを、なければIndex out of rangeのエラーを返す。これはobjectWillChangeがあってもなくても関係ないので覚えておくこと。

Realm Swift + SwiftUI でテーブル表示・編集・削除のページにもあるようにRealmSwift.Resultsではなく、それを配列に変換したものなどを使うと良い。

TabView の場合#

TabView の場合、NavigationView のように別のビューが表示されている扱いではなく「全てのタブが同時に表示されている」ような状態になっている。

なので例えば、A、B、C 三つのタブがあり、A のタブでForEachでレコードの中身を表示していて B のタブでプライマリキーが設定されているレコードの削除を行うとInvalidateがでる。

また、NavigationView と違い、View を再表示したときに強制再レンダリングが発生しないためobjectWillChangeを書かないと何も反映されない。

::: tip TabView と NavigationView の違い

要するに「TabView において A でレコード表示、B でレコード削除」というのは「一つの View でレコード表示、レコード削除」をしているのとほとんど同じ状態になっている。

ただし、index out of rangeのエラーは何故か発生しないのでプライマリキーが設定されていないのであればエラーは起きない。ここが不思議なところの一つである。ただし、NavigationView と同じように「A でレコード表示、A でレコード削除」とすればやはりindex out of rangeが発生する。

:::