О
по архитектуре у дядюшки Боба книжка есть, почитай
читал
Size: a a a
2020 October 06
MK
данные из контекста а обработчики в хуках
ага то есть плюс к этому еще стм свой на контекстах?
О
по архитектуре у дядюшки Боба книжка есть, почитай
я к ней стремлюсь да.
VK
по архитектуре у дядюшки Боба книжка есть, почитай
Она про принципы, а не про конкретные вещи. И больше про бек
VK
идеальный компонент это где есть jsx без прокидываний пропсов и где есть вызовы пользовательских хуков и больше ничего) стремлюсь к этому
Откуда такое определение "идеального компонента"?
О
Откуда такое определение "идеального компонента"?
ну есть опыт работы с таким кодом (написан не мною). и от чистоты компонентов получаю удовольствие)))
AE
Она про принципы, а не про конкретные вещи. И больше про бек
без разницы к чему эти принципы применять
если у человека разделение на 100500 файлов работает, значит хорошо
если у человека разделение на 100500 файлов работает, значит хорошо
VK
без разницы к чему эти принципы применять
если у человека разделение на 100500 файлов работает, значит хорошо
если у человека разделение на 100500 файлов работает, значит хорошо
Их применение не всегда очевидно, особенно в современном фронтенде
VK
ну есть опыт работы с таким кодом (написан не мною). и от чистоты компонентов получаю удовольствие)))
Про "отсутствие пропсов" - вообще не согласен.
Не понимаю, почему люди считают, что пропсы - это плохо
Не понимаю, почему люди считают, что пропсы - это плохо
AE
Их применение не всегда очевидно, особенно в современном фронтенде
если бы это было так очевидно, не было бы архитекторов с зарплатой в полмиллиона )
О
Про "отсутствие пропсов" - вообще не согласен.
Не понимаю, почему люди считают, что пропсы - это плохо
Не понимаю, почему люди считают, что пропсы - это плохо
я хз почему так считают но предполагаю из-за меньших связей между компонентами
А
идеальный компонент это где есть jsx без прокидываний пропсов и где есть вызовы пользовательских хуков и больше ничего) стремлюсь к этому
Мне кажется гораздо удобнее иметь композицию компонента, который отвечает за получение данных и компонента, в который они прокидываются через пропсы, в тулзах реактовских тогда всё нагляднее.
VK
я хз почему так считают но предполагаю из-за меньших связей между компонентами
Вместо явных связей вы делаете неявные, чем это лучше?
О
Вместо явных связей вы делаете неявные, чем это лучше?
почему? есть стейт от которого зависит компонент и больше ничего
А
Мне кажется гораздо удобнее иметь композицию компонента, который отвечает за получение данных и компонента, в который они прокидываются через пропсы, в тулзах реактовских тогда всё нагляднее.
Особенно, если учесть, что ни реакт тулзы, ни редакс тулзы не умеют в нормальный мониторинг заюзанных селекторов (
VK
почему? есть стейт от которого зависит компонент и больше ничего
Стейт, от которого зависит несколько компонентов, они изменяют это состояние и полагаются на то как работает с этим состоянием другой компонент. А это уже связь, но неявная.
Например, один компонент загрузил данные в хранилище, а другой ведет себя так, будто там они уже есть.
Например, один компонент загрузил данные в хранилище, а другой ведет себя так, будто там они уже есть.
О
Стейт, от которого зависит несколько компонентов, они изменяют это состояние и полагаются на то как работает с этим состоянием другой компонент. А это уже связь, но неявная.
Например, один компонент загрузил данные в хранилище, а другой ведет себя так, будто там они уже есть.
Например, один компонент загрузил данные в хранилище, а другой ведет себя так, будто там они уже есть.
но ведь лучше кода у тебя один источник изменения компонента а не несколько (пропсы и общий стейт например). по крайней мере, вижу так
MK
что то я уже запутался, то пропсы это зло, то пропсы уже можно
VP
Их применение не всегда очевидно, особенно в современном фронтенде
вот как раз в современном фронтенде уже почти без разницы - бэк у тебя, мобилка, pwa или еще что.
приложение - оно и есть приложение, абстракции работают одинаково практически. clean там, ddd, hexagonal или что угодно еще взять
приложение - оно и есть приложение, абстракции работают одинаково практически. clean там, ddd, hexagonal или что угодно еще взять
A
но ведь лучше кода у тебя один источник изменения компонента а не несколько (пропсы и общий стейт например). по крайней мере, вижу так
лучше, когда данные берутся из нужных мест
пропсы - для реюза в основном, тащемта, остальное прибивается гвоздями внутри компонента
пропсы - для реюза в основном, тащемта, остальное прибивается гвоздями внутри компонента