Привет. А куда и в каком виде вы обычно выносите

хэндлеры событий компонента?

А зачем их куда-то из компонента выносить?

чтобы компоненты были тонкие. не люблю когда компонент больше 40-50 строк

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

я бы хотел всё вынести в хуки но пока не пойму как потому что по факту это просто метод. надо подумать как сделать удобно и чтобы код был читаемым. насчет размызывания не увеерен потому что у IDE есть быстрый способ перейти к методу

В хуки можно вынести. Просто из хука возвращайте хендлеры и нужные для компонента пропсы

сами импорты могут занимать 40-50 строк🌚

это очень плохо

Ну так импорты в одном файле, jsx- в другом, хуки - отдельно, css - отдельно🤣

ок. попробую, спасибо.

и получим ангуляр)

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

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

у тебя был продакшен опыт?

Короче, "не люблю компоненты больше 40 строк" - это просто личный "фетишь", который никакого качества не гарантирует и ничего о вашем коде не говорит)

сейчас начался интересный опыт. и поэтому возникают такие вопросы

интересный опыт в плане что на проекте все файлы не больше 50 строк?

это понятно. но это может косвенно сказать о том что проект неплохо спроектирован и вся логика не хранится в UI

Нет времени точить пилу — надо лес валить

Нет, не может. "логика хранится в UI" В ui логики столько может быть, что вам и не снилось. И дробить это на миллион файлов - фиговая идея.

Мерять качество количеством строк — заведомо провальная идея. Нет прямой корреляции, только косвенная. И зависит от кучи других параметров. Вынести обработчики событий из компонента — хуже подход сложно придумать

мне на работе на ангуляре достались компоненты почти под 1000 строк))

после аутсорсеров

Это уже беда, ибо как мне кажется, в любом фрейме нужно декомпозировать настолько, насколько это реально, чтобы проще было искать что к чему и где

идеальный компонент это где есть jsx без прокидываний пропсов и где есть вызовы пользовательских хуков и больше ничего) стремлюсь к этому

Бог в помощь. Через год будешь стремиться обратно, если не ливнёшь из проекта

тоесть для тебя идеально что бы все данные для компонента брались из кастомных хуков?

по архитектуре у дядюшки Боба книжка есть, почитай

данные из контекста а обработчики в хуках

читал

ага то есть плюс к этому еще стм свой на контекстах?

я к ней стремлюсь да.

Она про принципы, а не про конкретные вещи. И больше про бек

Откуда такое определение "идеального компонента"?

ну есть опыт работы с таким кодом (написан не мною). и от чистоты компонентов получаю удовольствие)))

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

Их применение не всегда очевидно, особенно в современном фронтенде

Про "отсутствие пропсов" - вообще не согласен. Не понимаю, почему люди считают, что пропсы - это плохо

если бы это было так очевидно, не было бы архитекторов с зарплатой в полмиллиона )

я хз почему так считают но предполагаю из-за меньших связей между компонентами

Мне кажется гораздо удобнее иметь композицию компонента, который отвечает за получение данных и компонента, в который они прокидываются через пропсы, в тулзах реактовских тогда всё нагляднее.

Вместо явных связей вы делаете неявные, чем это лучше?

почему? есть стейт от которого зависит компонент и больше ничего

Особенно, если учесть, что ни реакт тулзы, ни редакс тулзы не умеют в нормальный мониторинг заюзанных селекторов (

Стейт, от которого зависит несколько компонентов, они изменяют это состояние и полагаются на то как работает с этим состоянием другой компонент. А это уже связь, но неявная. Например, один компонент загрузил данные в хранилище, а другой ведет себя так, будто там они уже есть.

но ведь лучше кода у тебя один источник изменения компонента а не несколько (пропсы и общий стейт например). по крайней мере, вижу так

вот как раз в современном фронтенде уже почти без разницы - бэк у тебя, мобилка, pwa или еще что. приложение - оно и есть приложение, абстракции работают одинаково практически. clean там, ddd, hexagonal или что угодно еще взять

лучше, когда данные берутся из нужных мест пропсы - для реюза в основном, тащемта, остальное прибивается гвоздями внутри компонента

Покажите мне "hexagonal" на фронте от которого не больно

+

Пропсы - хороший явный контракт, который компонентом декларируется.

Взамен на большую связность всего приложения 👍🏿

я не говорил что не больно. больно, но иногда приходится. но это проще, чем внутренностями того же firebase обмазывать всё, а потом долго переезжать на что-то другое. но да, мне мобилки ближе сейчас, чем web, там это заметнее.

А если прокидывать в компонент селектор, с объявлением интерфейса, который должен реализовывать результат этого селектора?)

Я вчера слышал, что в реакте на rescript так и работает все. Там нет контекста как раз потому, что "явное лучше неявного".

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

контракты как идея в js так себе кто угодно откуда угодно этим контрактам третью руку к жопе приделает и норм

Контракты в js - единственный способ писать надежно) Просто за их нарушение надо больно бить))

это типа перед и после действия можно сайд эффекты делать ?

не понял к чему вы

контрактное

контракты это везде хорошо, просто где-то их нарушить нельзя, а где-то хер найдешь, где их кто нарушил)

Ну, тут подход не виноват)

скажем, он "не работает" с этим замечательным языком)

Я как-то сам до этого дошёл, но начал напрягать тот момент, что вроде компоненты получаются реюзабильными, но сильно привязанными к либам, которые отвечают за реализацию селекторов, но может это и не плохо, хз, просто нигде про такое не слышал, надо будет почитать про rescript, спасибо.)