Д
ну и зачем такая сложность?
Чтоб инкапсулировать логику, чтоб при обработке эффекта ты просто вызвал метод получения данных и не ебал мозг откуда они придут, плюс возможное дублирование логики убирается
Size: a a a
2020 August 13
AM
ну и зачем такая сложность?
SRP же. Каждый по-своему софт педалит, чё вы к человеку пристали.
Д
как ты будешь поступать, если у тебя в одном месте чему-то нужно получить свежие данные, в другом - свежие или кеш в случае ошибки, а в третьем - кеш. три гейтвея пилить?
Не встречал таких примеров
AD
SRP же. Каждый по-своему софт педалит, чё вы к человеку пристали.
ну, все вроде с того началось, что ему очень хотелось понять, как быть с обработчиком, а скатилось проталкиванию своей позиции
ладно, капитулируюсь)
ладно, капитулируюсь)
Д
SRP же. Каждый по-своему софт педалит, чё вы к человеку пристали.
Не я хочу делать правильно и если я не прав я буду благодарен если мне объяснят почему я не прав
Д
Но я не вижу убедительных аргументов
AM
Не я хочу делать правильно и если я не прав я буду благодарен если мне объяснят почему я не прав
Дык тут нет "правильно" и "неправильно" же, вы видите ценность в вынесении этой логики в гейтвэй, Алексей нет, только и всего.
AD
Но я не вижу убедительных аргументов
самый убедительный аргумент - собственное нежелание писать ненужные абстракции и лишний код, а это очень индивидуально)
Д
самый убедительный аргумент - собственное нежелание писать ненужные абстракции и лишний код, а это очень индивидуально)
Так а дублирование кода избежать тоже неплохая цель
AM
Но я не вижу убедительных аргументов
Если вам кажется, что смешение разных ответственностей в одном редьюсере -- это прям плохо, значит TEA просто не для вас. И в этом нет ничего такого 🤷♂ Потому я и говорю, каждому своё. Благо, компоуз должен поддерживать разные подходы построения не-юайной части приложений.
Д
как ты будешь поступать, если у тебя в одном месте чему-то нужно получить свежие данные, в другом - свежие или кеш в случае ошибки, а в третьем - кеш. три гейтвея пилить?
Можешь привести пример когда требуется такое разное повеление?
AD
Можешь привести пример когда требуется такое разное повеление?
экран профиля - свежие данные для возможного редактирования
получить и отобразить имя где-нибудь в углу - кеш
какой-нибудь диалог - актуальные, но можно и кеш
получить и отобразить имя где-нибудь в углу - кеш
какой-нибудь диалог - актуальные, но можно и кеш
Д
экран профиля - свежие данные для возможного редактирования
получить и отобразить имя где-нибудь в углу - кеш
какой-нибудь диалог - актуальные, но можно и кеш
получить и отобразить имя где-нибудь в углу - кеш
какой-нибудь диалог - актуальные, но можно и кеш
Ну это же разные модели, верно?
Д
В плане то что свежее и то что кеш
AD
как? профиль - одна и та же моделька: имя, фамилия, мыло
Д
То есть при отображении загружаются данные и кешируются а при диалоговом окне берется только из Кеша, верно?
AD
То есть при отображении загружаются данные и кешируются а при диалоговом окне берется только из Кеша, верно?
да, например
Д
да, например
Понял, да в таком случае имеет место быть разное поведение, но я бы это в usecase обработал бы в плане отдельно обновить данные когда это нужно и отдельно получить только с кеша, хотя может это излишнее усложнение логики, не буду спорить
AD
Понял, да в таком случае имеет место быть разное поведение, но я бы это в usecase обработал бы в плане отдельно обновить данные когда это нужно и отдельно получить только с кеша, хотя может это излишнее усложнение логики, не буду спорить
ну вот ровно здесь теряется смысл в каком гейтвее, когда каждый бизнес-сценарий требует понимания, откуда мы все-таки данные берем
Д
Ну да, согласен