я бы добавил еще сюда излишнюю переиспользуемость. Когда пишут компоненты которые используются условно в двух-трех местах, например это какой нить блок на сайте. Но часто приходят правки от бизнеса поправить в одном блоке что нибудь, и этот компонент начинает разрастаться конфигами, условиями и тд. Вместо того чтобы написать три разных блока, но использовать в них более мелкие компоненты типа ui-kit
@@Kysok410только хотел написать, что если есть одинаковые компоненты которые мало чем отличаются идеально подходит compound component и переиспользуемость становится практичнее и можно его использовать для разделения кода тоже. Возможно для людей, которые только на проект зашли запомнить сразу тяжело, но при поддержке проекта становится очень просто внести в какие то компоненты изменения
Проблемы "state coupling" не понял, обычно же если ты хочешь чтобы компонент использовался только в рамках одного стора то ты "завязываешь" его на одном сторе, если нужно что-то общее как например Table, TableCell etc. то ты делаешь "глупые компонент" так как просто не можешь завязывать это на стор
Стоимость курса отдельно, также как у сообщества, выгоднее не будет) Если возможности приобрести сообщество нет, могу предложить разделить оплату на 2 части. Для этого напиши в поддержку в телеграм @microcourses_support
1. God Component. Сразу ДА. Как же раздражает. Просто без сепарации ответственности столько проблем на ровном месте создают 450 строк это ещё по божески. Постоянно попадаются легаси у которых 1000 или 2000 строк. Это же просто невозможно поддерживать
@HiroNakamura1991 встречаю такие и на react) при чем не легаси. Иногда импорты только строк на 50) Тут правда еще от преттиера зависит, можно и в одну строку всё отобразить)
Хорошее видео, лайк. Про components folder непонятно только. Хуки (хелперы, константы) выносятся в папку так как они переиспользуются (или могут переиспользоваться) в разных компонентах. Разве нет?
переиспользуемые (глобальные) сущности выносятся на глобальный уровень. здесь была речь о локальных сущностях, тесно связанных друг с другом и которые без друг друга не используются. вот их нужно хранить рядом. часто ВСЕ хуки выносят в папку hooks в корне проекта просто потому что эта папка уже есть и кажется что там нужно хранить все хуки. но это не так
На сервере, но опять же, не все нужен ssr. Так что считаю этот антипаттерн притянутым за уши. А если люди пишут логику в useEffect как показано в видео, то возникают вопросы о их квалификации и даже джуны такое не напишут в здравом уме, особенно кто доку по react прочитает. P.s. все же есть еще вариант который не указал. react-router loader api
К сожалению пишут и не джуны, очень очень много пишут (как человек который видел много проектов и с многими людьми общался говорю) По поводу useEffect есть кейсы где он нужен, но как и написано в доке это не должно быть настолько часто
Не не не. Сам часто сталкивался с тем, что в компоненте по 2-3 useEffect-a тупо для того, чтобы засетать стейт на основе другого стейта. Прям бесит. Видимо - самое простое, что приходит в голову неопытному или ленивому спецу.
Пункт №4 - это моя боль. Мозгов не хватает, как бы это решить. Посмотрел паттерн медиатор, и я тоже в этом направлении смотрел, но как от этого профит получить, не понял. Как по мне, лучше уж локальные стейты с редюсером и контекстом иметь их можно переиспользовать. Но тогда будут перерендеры на каждый чих. Ну хотя бы серверные данные c swr / react-query использовать уже неплохо.
Да легко решается. Тот же принцип единой ответственности по сути. На глобальный стейт должен завязываться и управлять компонент на том максимальном уровне, который с ним работает. Например, компонент, управляющий страницей или крупным блоком на странице. А внутри него уже «глупые компоненты», которые просто принимают параметры и колбэки на определённые события. Это немного противоречит проблеме проп-дриллинга, но на самом деле не так страшен проп-дриллинг, как неверное его использование (неправильная декомпозиция). Контекст тоже не всегда подходит: он ререндерит все подписанные компоненты при изменении своего значения. Также не надо всё вподряд тащить в глобальный стейт. Например, раскрыт ли визуально тот или иной компонент или показана ли подсказка. транице.
@@nilsen1879 «медиатор» довольно распыленный паттерн, его можно увидеть во многих паттернах отчасти. Многие путают его с «наблюдателем», но он больше подходит к «шине событий».
Сейчас я эти паттерны раскрываю в своём курсе в сообществе. Это видео как раз начало этого курса. Позже, когда я их проработаю, собираюсь выпустить в открытый доступ
я бы добавил еще сюда излишнюю переиспользуемость. Когда пишут компоненты которые используются условно в двух-трех местах, например это какой нить блок на сайте. Но часто приходят правки от бизнеса поправить в одном блоке что нибудь, и этот компонент начинает разрастаться конфигами, условиями и тд. Вместо того чтобы написать три разных блока, но использовать в них более мелкие компоненты типа ui-kit
о дарова Сань)
можно было бы еще рассказать про compound подход
пример с таблицами был бы хороший
@@Kysok410 салют))
@@Kysok410только хотел написать, что если есть одинаковые компоненты которые мало чем отличаются идеально подходит compound component и переиспользуемость становится практичнее и можно его использовать для разделения кода тоже. Возможно для людей, которые только на проект зашли запомнить сразу тяжело, но при поддержке проекта становится очень просто внести в какие то компоненты изменения
Спасибо за поднятие актуальных проблем, ждем курс по паттернам!
Очень классное видео. Лично мне не хватило на каждый антипаттерн итог "как бы это выглядело при хорошем подходе"
плоти за курс. очень хочется узнать, да? что аж проскакивает мысль а не сходить ли на курс ) значит автор добился своей цели, мои поздравления )
@@factorealrus он же вроде сказал в следующем ролике здесь скажет
@@factorealrus ну а почему б не сходить тогда? если курс будет тебе полезен
@@le6ka71 это был сарказм. Не приемлю все эти курсы как явление.
@@factorealrus И в школе тоже не учились?
Проблемы "state coupling" не понял, обычно же если ты хочешь чтобы компонент использовался только в рамках одного стора то ты "завязываешь" его на одном сторе, если нужно что-то общее как например Table, TableCell etc. то ты делаешь "глупые компонент" так как просто не можешь завязывать это на стор
А нельзя ли будет приобрести курс отдельно про паттерны ? Если нет возможности оплатить вход в сообщество.
Стоимость курса отдельно, также как у сообщества, выгоднее не будет)
Если возможности приобрести сообщество нет, могу предложить разделить оплату на 2 части. Для этого напиши в поддержку в телеграм @microcourses_support
Спасибо, очень полезно.
Какой плагин в vscode показывает зависимости переменной или компонента без использования Find?
ПКМ по переменной => Find all references
либо
Command + P => вводим #{{variableName}}
1. God Component. Сразу ДА. Как же раздражает. Просто без сепарации ответственности столько проблем на ровном месте создают
450 строк это ещё по божески. Постоянно попадаются легаси у которых 1000 или 2000 строк. Это же просто невозможно поддерживать
бл**$#* после того как разобрался в подобном легаси, нормальный код кажется уж банально простым))
но эт явно не на react js писаные !
@HiroNakamura1991 встречаю такие и на react) при чем не легаси. Иногда импорты только строк на 50)
Тут правда еще от преттиера зависит, можно и в одну строку всё отобразить)
такая жиза, на одном проекте было множество компонентов в среднем от 300 и до 1200 строк, тут даже слов не подобрать
@@jacktwinn аналогичная ситуация, причем даже это не классовые компоненты, а функциональные с РКТ
Очень много годной инфы и слушать приятно🔥🔥🔥
Хорошее видео, лайк. Про components folder непонятно только. Хуки (хелперы, константы) выносятся в папку так как они переиспользуются (или могут переиспользоваться) в разных компонентах. Разве нет?
переиспользуемые (глобальные) сущности выносятся на глобальный уровень. здесь была речь о локальных сущностях, тесно связанных друг с другом и которые без друг друга не используются. вот их нужно хранить рядом. часто ВСЕ хуки выносят в папку hooks в корне проекта просто потому что эта папка уже есть и кажется что там нужно хранить все хуки. но это не так
Спасибо большое, очень интересно и полезно!
Спасибо. А как во вью решаются данные проблемы ?
Ровно также, как и в реакт. Но, к сожалению, во вью распространена мутабельные структуры данных, поэтому там ещё все хуже
зато ререндеры оптимизировать не нужно и нести чушь по преждевременную оптимизацию)
1:02:03 Так, а где мы будем выполнять сайдэффекты, например ajax?)
Вариант с танстаком юзает эффект
На сервере, но опять же, не все нужен ssr. Так что считаю этот антипаттерн притянутым за уши. А если люди пишут логику в useEffect как показано в видео, то возникают вопросы о их квалификации и даже джуны такое не напишут в здравом уме, особенно кто доку по react прочитает.
P.s. все же есть еще вариант который не указал. react-router loader api
К сожалению пишут и не джуны, очень очень много пишут (как человек который видел много проектов и с многими людьми общался говорю)
По поводу useEffect есть кейсы где он нужен, но как и написано в доке это не должно быть настолько часто
Не не не. Сам часто сталкивался с тем, что в компоненте по 2-3 useEffect-a тупо для того, чтобы засетать стейт на основе другого стейта. Прям бесит. Видимо - самое простое, что приходит в голову неопытному или ленивому спецу.
Благодарю. Евгений лучший учитель и ментор🎉
30:40
Зачем хвастаться тем, что ты импользуешь другие методы оптимизации, не сказав про них практически ни слова? ))
React 19 не бурет разве работу useMemo на себя?
Просто лучший, спасибо тебе
Отличны ролик! Огромное спасибо! Очень полезная информация.
Говорить в начале видео, что все пишут хреново, потому что не знают КАК и не сказать за час КАК писать то
Сэкономил время, спасибо друг
39:30 Ну если нет навыка разделять бизнес-логику от UI - не поможет ни стм, ни пропрс-дриллинг 😅
Классный видос, спасибо
Отлично!!!
Пункт №4 - это моя боль. Мозгов не хватает, как бы это решить. Посмотрел паттерн медиатор, и я тоже в этом направлении смотрел, но как от этого профит получить, не понял. Как по мне, лучше уж локальные стейты с редюсером и контекстом иметь их можно переиспользовать. Но тогда будут перерендеры на каждый чих. Ну хотя бы серверные данные c swr / react-query использовать уже неплохо.
Да легко решается. Тот же принцип единой ответственности по сути. На глобальный стейт должен завязываться и управлять компонент на том максимальном уровне, который с ним работает. Например, компонент, управляющий страницей или крупным блоком на странице. А внутри него уже «глупые компоненты», которые просто принимают параметры и колбэки на определённые события. Это немного противоречит проблеме проп-дриллинга, но на самом деле не так страшен проп-дриллинг, как неверное его использование (неправильная декомпозиция). Контекст тоже не всегда подходит: он ререндерит все подписанные компоненты при изменении своего значения.
Также не надо всё вподряд тащить в глобальный стейт. Например, раскрыт ли визуально тот или иной компонент или показана ли подсказка.
транице.
@@nilsen1879 «медиатор» довольно распыленный паттерн, его можно увидеть во многих паттернах отчасти. Многие путают его с «наблюдателем», но он больше подходит к «шине событий».
Шестой попал в мою боль.
а когда будет видео с тем, как ты показываешь, как правильно?
Сейчас я эти паттерны раскрываю в своём курсе в сообществе. Это видео как раз начало этого курса.
Позже, когда я их проработаю, собираюсь выпустить в открытый доступ
Ну получается, 5 правил SOLID свели получается, к одному, что получается, мучились раньше 🤔
Смысл хороший, но было бы здорово, если бы это всё было ужато максимум в 20 минут
Первая ошибка реакт разработчика - писать на реакт
конструктивно
3. Даааааа, какая же жиза
Что за AI писал проекты?
windsurf
Топ
Евгений Паромов | Front-end, наверное тебе нужно изменить react на svelte, vue, solid.
Дружище не хочу хейтить, но поработай над своей речью, у тебя слово паразит "получается" в каждом предложении по нескольку раз звучит, слушать тяжело.
Буквально пару видосов назад этим заболел(
Сейчас активно исправляю...
а никто не заметил миллион "вот это вот все"? после 40 минут видео прям дико бросается в глаза. но сам видос полезный, спасибо