Bring mvvm architecture + colorscheme usage #5
Conversation
mike56k
commented
Aug 27, 2022
mike56k
commented
- Выделил главный экран в виде отдельного модуля Feed
- В рамках модуля есть FeedView и FeedViewModel
- FeedViewModel взяла на себя ответственность за обращение к RazrabsApi
- В рамках каждого модуля будет создаваться экстеншн на Color, как в данном случае Color+Feed
- Добавил бэкграунд цвет как на сайте для FeedView зависящий от ColorScheme
There was a problem hiding this comment.
спасибо за ПР, но есть проблема: у меня локально уже сделана ViewModel. Если я ее запушу ты получишь мерж конфликты. Если ты тоже хочешь участвовать в проекте, то давай лучше это сначала обсудим чтобы как минимум иметь одинаковые взгляды на реализацию. А иначе получается лебедь, рак и щука
| @@ -0,0 +1,56 @@ | |||
| import SwiftUI | |||
|
|
|||
| struct FeedView<VM: FeedViewModel>: View { | |||
There was a problem hiding this comment.
зачем модель выделять как аргумент дженерика?
There was a problem hiding this comment.
это способ, с помощью которого можно закрыть вьюмодель протоколом и использовать во View.
реализацию вьюмодели можно подменять, полезно для тестов
There was a problem hiding this comment.
ок. Спрашиваю потому что по факту у тебя этот функционал нигде не используется, то есть, выглядит как оверинжиниринг
| @Published var feedItems = [FeedItem]() | ||
| private let razrabsApi: RazrabsApi | ||
|
|
||
| init(razrabsApi: RazrabsApi) { |
There was a problem hiding this comment.
зачем делать активную модель? RazrabsApi это сервис. Модель, которая стучится в сервис выглядит как очень странный архитектурный подход. Логичнее оставить взаимодействие с сервисами у страницы, которая по сути является тем, чем раньше был контроллер, а модель оставить пассивную
There was a problem hiding this comment.
в моем понимании mvvm подразумевает как раз активную viewmodel, отвечающую за бизнес логику и взаимодействие с сервисами.
есть пассивные model, просто структуры данных.
view нужна для отображения данных полученных из viewmodel, в ней желательно чтобы была только верстка
There was a problem hiding this comment.
понятно. Я активный несторонник активной модели просто потому что кода получается больше, а выглядит он крайне нетипично. По факту мы события из view пересылаем в модель, хотя можем сами на месте разрулить эту логику. MVVM не ограничивается только вариантом с активной моделью. Это корпоративные варианты реализации данной архитектуры иногда так делают видимо в порыве сделать что-то похожее на ту архитектуру, которую Apple показывает в примерах (а у них модель активная). Как по мне активная модель это такая архитектура джуна просто потому что в самых разных языках и фрэймворках чаще всего модель не активная. Я лично не вижу смысла следовать идеям Apple в плане архитектуры потому что в архитектуру они точно не умеют. Потому мой вариант очень похож на классический MVC только большая часть кода контроллера упакована в биндинги благодаря SwiftUI, а класс MainView, например, имеет отображение в свойстве body и логику в событиях как это раньше делал контроллер
| } | ||
|
|
||
| case .failure(let error): | ||
| print("error = \(error)") |
There was a problem hiding this comment.
как репортить в отображение факт того, что случилась ошибка?
There was a problem hiding this comment.
создать во ViewModel published свойство isErrorOccured и обычное свойство errorDescription. при возникновении ошибки записывать в errorDescription текст ошибки и ставить isErrorOccured = true. во view сделать условие
if viewModel.isErrorOccured {
Text(viewModel.errorDescription)
}
There was a problem hiding this comment.
понятно. Да, можно так, но если эту же логику реализовать во view, то кода тупо будет меньше
| enum Feed { | ||
|
|
||
| static func background(colorScheme: ColorScheme) -> Color { | ||
| return colorScheme == .dark ? Color(r: 31, g: 32, b: 37) : Color(r: 247, g: 248, b: 252) |
