На сколько адекватно вносить логику в Класс ячейки?

#1

Добрый вечер, такой вопрос, на сколько адекватно внести логику в класс ячейки? Под логикой подразумевается обработка события и взаимодействия через класс service с сервером! или такие моменты не должны проявляться в таких, в принципе, не кто ведь не запрещает для класса ячейки прописать viewModel а оттуда делать запросы) Или это не этично в мире Свифт?!

#2

Не адекватно. Ячейка нужна только для отображения данных. Туда можно внести логику, которая влияет на анимацию, отображение данных и все. Все события с ячейки надо выносить наружу. Контроллеру, который и будет решать что делать при свайпах, тачах и пр.

Ячейки должны переиспользоваться в идеале. Поэтому хорошо если у них будет конфигуратор, который будет принимать не модель, а протокол даже. И данные раскидывать по аутлетам.

#3

А если сделать отдельный класс VM для класса ячейки, а в ячейки сделать билдинг к VM, на такие вещи тоже табу?

#4

Не знаю, в общем забиндил так)

viewModel.usersSubject
                .bind(to: tableView.rx.items(cellIdentifier: AddUserCell.reuseIdentifier, cellType: AddUserCell.self)) {
                    [weak self] (row, element, cell) in
                    cell.configure(element: element)
                    
                    cell.addButton.rx.tap.map{ _ in cell.model}
                        .bind(to: self!.viewModel.user)
                        .disposed(by: self!.bag)
                }
                .disposed(by: bag)
#5

В случае с реактивщиной - ничего не скажу. Сам только начал эту тему копать. Но чисто логически, не хорошо когда ячейка кучу всего умеет. А что если ее надо будет переиспользовать?
Простой пример у меня был. Была доморощенная ячейка, где был и цвет и анимация заливки (процент заполнения) и текст и один лейбл показать, другой скрыть итп.

Туда передавал протокол, который все это заполнял. Тапов специфических не было, но если бы и были, я бы их вынес в контроллер.

В данном случае, может и нормально что ты на тап кнопки вешаешь связь с юзером.

Что точно нельзя делать, так это force unwrap. Напиши после in:

guard let sSelf = self else { return }
и дальше используй sSelf, а не self!.

И в твоем случае, сама ячейка логики не содержит. Ты же этот метод пишешь в контроллере. Верно?

#6

Да, верно)
Я просто думал для ячейки сделать класс viewModel и пустить с button связь к нему, а в View model вызывать метод из класса что с сервером общается, а потом попробовал с биндить все в контроллере и оно сработало, по крайним мерам пока на ошибки не напоролся)

#7

Я понимаю, просто вот в каком случае self может не существовать? всю жизнь небезопасно анвраплю в слабых ссылках self и не разу не сталкивался с ошибкой из-за этого, вот честно)
Вот столкнусь однажды и может начну, а пока это будет лишний код) Либо может у тебя был опыт ошибок на этом) тогда делись

#8

используйте тогда [unowned self] и не нужно тогда принудительно извлекать опционал.
но лучше всего использовать [weak self] … self?..

#9

Вот тут я натыкался на ошибку, он ведь вроде живет либо столько же сколько, либо больше, и была на памяти с ним ошибка, как у меня так и у коллеги) Но вот ей богу не помню в чем именно, а с weak всегда все хорошо проходило, но опять же, если наткнусь, то изменю подход)

#10

В вашем случае [weak self] … self! - тоже самое что и [unowned self] … self

#11

Возможно, я не очень хорошо понимаю, что 100% необходимо использовать и когда

#12

У меня был случай когда я ошибку выхватил. Было связано с переходами на другие контроллеры.
Поэтому проще перестраховаться. Хотя если все в рамках одного контроллера работает, то пользуй тогда [unowned self]

#13

так в этом и суть, что я обжигался на нем) Нужно сначала разобраться будет что к чему и когда уместно использовать первое или второе) Так как пока знания этого момента основаны только на оф. документации) А каких-то опытных исследований не проводил, чтобы прям понять понять)