DEV Community
·
在简单的SwiftUI屏幕中使用ViewModel处理列表和API调用是否错误？有没有更好的方法？
内容提要
我正在构建一个SwiftUI屏幕，显示通知列表，并使用ViewModel处理状态和API调用。尽管有文章质疑在简单视图中使用ViewModel的必要性，但我发现将逻辑移入View会导致代码混乱，因此决定继续使用ObservableObject ViewModel，以实现更好的关注点分离。
关键要点
-
正在构建一个SwiftUI屏幕，显示通知列表，使用ViewModel处理状态和API调用。
-
屏幕包含一个标题和一个支持下拉刷新和无限滚动的分页通知列表。
-
有文章质疑在简单视图中使用ViewModel的必要性，作者对此表示怀疑。
-
作者决定继续使用ObservableObject ViewModel，以实现更好的关注点分离。
-
NotificationListViewModel类负责管理通知列表的状态和API请求。
-
NotificationState枚举定义了不同的状态：加载中、已加载、分页、空和错误。
-
loadMoreNotification方法用于加载更多通知并更新状态。
-
resetNotification方法用于重置通知列表并重新加载通知。
-
shouldLoadMore方法用于判断是否需要加载更多通知。
-
NotificationListView结构体定义了视图的布局和状态处理。
-
在视图中使用了不同的状态视图，包括加载视图、通知列表和错误视图。
-
作者尝试将所有逻辑放入视图中，但发现代码变得混乱，因此选择使用ViewModel。
延伸问答
在SwiftUI中使用ViewModel的好处是什么？
使用ViewModel可以实现更好的关注点分离，使代码更清晰易于维护。
NotificationListViewModel类的主要功能是什么？
NotificationListViewModel类负责管理通知列表的状态和API请求。
如何处理加载更多通知的逻辑？
通过shouldLoadMore方法判断是否需要加载更多通知，并调用loadMoreNotification方法进行加载。
在视图中如何处理不同的状态？
视图通过switch语句处理不同的状态，包括加载中、已加载、分页、空和错误状态。
为什么作者选择不将所有逻辑放入视图中？
作者发现将所有逻辑放入视图中会导致代码混乱，因此选择使用ViewModel。
NotificationState枚举定义了哪些状态？
NotificationState枚举定义了加载中、已加载、分页、空和错误五种状态。
