DZ
в юз кейсах?
Size: a a a
2020 October 19
DZ
я бы так близко к сердцу не принимал то что пишет мартин, он даёт хорошие советы по общему стайлгайду и написанию кода, но принимать все рекомендации как истину не стоит. Каждая абстракция это трейдоф который замедляет тебя, но даёт какие-то дополнительные бенефиты в виде поддерживаемости кода или тестируемости
IA
в юз кейсах?
на сколько я понимаю юзкейсы скорее место где будет описано что поповер нужно открыть/закрыть. А где хрантися его состояние не дело юзкейса
IA
я бы так близко к сердцу не принимал то что пишет мартин, он даёт хорошие советы по общему стайлгайду и написанию кода, но принимать все рекомендации как истину не стоит. Каждая абстракция это трейдоф который замедляет тебя, но даёт какие-то дополнительные бенефиты в виде поддерживаемости кода или тестируемости
и я не принимаю близко к сердце. Просто пытаюсь рассуждать “а что если?”
DZ
и на разных этапах надо решать что более важно для проекта в текущем состоянии, двигаться быстро или делать меньше багов. Конечно с лапшой двигаться быстро не получится и именно по этому мы стараемся больше принимать принципы изоляции кода и компонентов (копипаста или овер реюз - копипаса будет меньшим злом), но как по мне правильной изоляции достаточно что бы развивать проект достаточно длительное время
DZ
и я не принимаю близко к сердце. Просто пытаюсь рассуждать “а что если?”
имхо применение таких тяжелых абстракций должно быть точечным и в зрелых проектах, а не простов проектах с 0 или совсем свежих
IA
имхо применение таких тяжелых абстракций должно быть точечным и в зрелых проектах, а не простов проектах с 0 или совсем свежих
не уверен что тут всегда речь идет о тяжелый абстракциях. В целом то моя главная претензия что мы сущности приравниваем к фичам. Хотя на мой взгляд тут даже в названии видно что это не совсем верно. Мы же не скажем что у нас есть фича “Post”, мы можем сказать что у нас есть фича “создание поста”. Мартина тут возможно я и зря притянул, но сам термин “варианты испозования” показался подходящим
DZ
не уверен что тут всегда речь идет о тяжелый абстракциях. В целом то моя главная претензия что мы сущности приравниваем к фичам. Хотя на мой взгляд тут даже в названии видно что это не совсем верно. Мы же не скажем что у нас есть фича “Post”, мы можем сказать что у нас есть фича “создание поста”. Мартина тут возможно я и зря притянул, но сам термин “варианты испозования” показался подходящим
так приравнивай не сущности юз кейс
DZ
просто юз кейс не из мартина а сам по себе
IA
так приравнивай не сущности юз кейс
чего?)
DZ
не знаю как довольно абстрактно описать, но по сути у тебя с тем же пользователем может быть связано несколько юз кейсов
DZ
логин и регистрация
проверка ролей
рдеактирования профиля
проверка ролей
рдеактирования профиля
DZ
настройки пользователя которые влият на приложение
DZ
но при этом это остаётся всё та же сущность юзера только с разных её сторон
DZ
ну и делать одну фичу user не стоит
IA
ну и делать одну фичу user не стоит
как тогда решить проблему с кросимпортами в фичах, если тот же юзер требуется в нескольких фичах?
DZ
я проблему с кросс импортами не решаю, если надо юзер в какой-то фиче и эта потребность логически обусловлена то зачем заморачиваться
IA
я проблему с кросс импортами не решаю, если надо юзер в какой-то фиче и эта потребность логически обусловлена то зачем заморачиваться
ну это конечно тоже вариант =)
2020 October 20
B
Всем привет!
Логика, типа клик на ListItem, навигация должен быть в templates или в pages?
Логика, типа клик на ListItem, навигация должен быть в templates или в pages?
FT
Всем привет!
Логика, типа клик на ListItem, навигация должен быть в templates или в pages?
Логика, типа клик на ListItem, навигация должен быть в templates или в pages?
Если речь не о бизнес-логике, где угодно. БЛ же может быть только в страницах или организмах