0

我正在寻找一些关于 SwiftUI 推荐做法的建议

当我们设计一个需要捕获用户输入的视图时，这些输入需要被捕获到一个模型对象中，该模型对象最终将被保存并稍后检索以显示在某些场景中，推荐什么

选项#1。每个子视图都有其本地 @State 变量，这些变量绑定到控件，如 TextField、Pickers、Toggle 等，然后我们应该编写一些代码将这些传递给模型对象

选项#1 的模型

struct PersonModel: Codable, Identifiable {
    var id: UUID
    var name: String
    var dateOfBirth: Date?
    var height: Double?
    var weight: Double?
}

选项#2。我们是否应该将模型的属性直接绑定到 TextField、Pickers、Toggle 等？

选项#2 的模型

struct PersonModel: Codable, Identifiable {
var id: UUID
var name: String
var dateOfBirth: Date?
var height: Double?
var weight: Double?

var heightInput: String {
    didSet {
        self.height = heightInput.DoubleOrNil()
    }
}

var weightInput: String {
    didSet {
        self.weight = weightInput.DoubleOrNil()
    }
}

}

在选项#1 中，我看到需要编写大量代码来捕获状态，然后将状态转移到模型，但在选项#2 中，状态已经在模型对象中捕获，因此代码更少。此外，任何触发其他属性更改的相互关系和依赖关系都可以在模型本身中编码（在 didSet 中）。例如，我可以将 heightInput 和 weight 输入绑定到 TextField 并提取 Model 本身中的底层值，而不是在 View 中处理 String 并将其转换为 View 中某处的 Double 类型属性

选项#3。就像我们将单个视图分解为子视图一样，我们是否也应该将模型（结构）分解为更小的子模型并将子模型分配给子视图？像下面

struct BodyStatictics {
    var heightInput: String {
        didSet {
            self.height = heightInput.DoubleOrNil()
        }
    }
    
    var weightInput: String {
        didSet {
            self.weight = weightInput.DoubleOrNil()
        }
    }
    
    var height: Double?
    var weight: Double?
}

struct BirthData {
    var dateOfBirth: Date?
    var location: String
}

struct PersonModel: Codable, Identifiable {
    var id: UUID
    var name: String
    var birthData: BirthData
    var bodyStats: BodyStatictics
}

struct MainView: View {
    @State private var modelInstance: PersonModel
    init(instance: PersonModel) {
        _modelInstance = State(initialValue: instance)
    }
    var body: some View {
        NameView(name: self.$modelInstance.name)
        BirthDataView(instance: self.$modelInstance.birhData)
        BodyStatisticsView(name: self.$modelInstance.bodyStats)
    }
}

在采用上述实践（或设计选择）之一之前，是否应该注意任何陷阱，以便现在可以避免以后的重构或管理不善？

我发现将模型的属性直接绑定到 UI 控件更容易，而不是在每个视图中创建本地 @State，因为它导致 UI 中的代码更少，模型中的代码集中。这是正确的评估还是错误的评估？

4

0 回答 0