я бы добавил еще сюда излишнюю переиспользуемость. Когда пишут компоненты которые используются условно в двух-трех местах, например это какой нить блок на сайте. Но часто приходят правки от бизнеса поправить в одном блоке что нибудь, и этот компонент начинает разрастаться конфигами, условиями и тд. Вместо того чтобы написать три разных блока, но использовать в них более мелкие компоненты типа ui-kit
1. God Component. Сразу ДА. Как же раздражает. Просто без сепарации ответственности столько проблем на ровном месте создают 450 строк это ещё по божески. Постоянно попадаются легаси у которых 1000 или 2000 строк. Это же просто невозможно поддерживать
Проблемы "state coupling" не понял, обычно же если ты хочешь чтобы компонент использовался только в рамках одного стора то ты "завязываешь" его на одном сторе, если нужно что-то общее как например Table, TableCell etc. то ты делаешь "глупые компонент" так как просто не можешь завязывать это на стор
Хорошее видео, лайк. Про 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
1. God Component. Сразу ДА. Как же раздражает. Просто без сепарации ответственности столько проблем на ровном месте создают
450 строк это ещё по божески. Постоянно попадаются легаси у которых 1000 или 2000 строк. Это же просто невозможно поддерживать
бл**$#* после того как разобрался в подобном легаси, нормальный код кажется уж банально простым))
Проблемы "state coupling" не понял, обычно же если ты хочешь чтобы компонент использовался только в рамках одного стора то ты "завязываешь" его на одном сторе, если нужно что-то общее как например Table, TableCell etc. то ты делаешь "глупые компонент" так как просто не можешь завязывать это на стор
Хорошее видео, лайк. Про components folder непонятно только. Хуки (хелперы, константы) выносятся в папку так как они переиспользуются (или могут переиспользоваться) в разных компонентах. Разве нет?
переиспользуемые (глобальные) сущности выносятся на глобальный уровень. здесь была речь о локальных сущностях, тесно связанных друг с другом и которые без друг друга не используются. вот их нужно хранить рядом. часто ВСЕ хуки выносят в папку hooks в корне проекта просто потому что эта папка уже есть и кажется что там нужно хранить все хуки. но это не так
1:02:03 Так, а где мы будем выполнять сайдэффекты, например ajax?)
Вариант с танстаком юзает эффект
На сервере, но опять же, не все нужен ssr. Так что считаю этот антипаттерн притянутым за уши. А если люди пишут логику в useEffect как показано в видео, то возникают вопросы о их квалификации и даже джуны такое не напишут в здравом уме, особенно кто доку по react прочитает.
P.s. все же есть еще вариант который не указал. react-router loader api
К сожалению пишут и не джуны, очень очень много пишут (как человек который видел много проектов и с многими людьми общался говорю)
По поводу useEffect есть кейсы где он нужен, но как и написано в доке это не должно быть настолько часто
Не не не. Сам часто сталкивался с тем, что в компоненте по 2-3 useEffect-a тупо для того, чтобы засетать стейт на основе другого стейта. Прям бесит. Видимо - самое простое, что приходит в голову неопытному или ленивому спецу.
Спасибо. А как во вью решаются данные проблемы ?
Ровно также, как и в реакт. Но, к сожалению, во вью распространена мутабельные структуры данных, поэтому там ещё все хуже
зато ререндеры оптимизировать не нужно и нести чушь по преждевременную оптимизацию)
Очень классное видео. Лично мне не хватило на каждый антипаттерн итог "как бы это выглядело при хорошем подходе"
плоти за курс. очень хочется узнать, да? что аж проскакивает мысль а не сходить ли на курс ) значит автор добился своей цели, мои поздравления )
@@factorealrus он же вроде сказал в следующем ролике здесь скажет
@@factorealrus ну а почему б не сходить тогда? если курс будет тебе полезен
@@le6ka71 это был сарказм. Не приемлю все эти курсы как явление.
@@factorealrus И в школе тоже не учились?
а когда будет видео с тем, как ты показываешь, как правильно?
Сейчас я эти паттерны раскрываю в своём курсе в сообществе. Это видео как раз начало этого курса.
Позже, когда я их проработаю, собираюсь выпустить в открытый доступ
а никто не заметил миллион "вот это вот все"? после 40 минут видео прям дико бросается в глаза. но сам видос полезный, спасибо
Классный видос, спасибо
Пункт №4 - это моя боль. Мозгов не хватает, как бы это решить. Посмотрел паттерн медиатор, и я тоже в этом направлении смотрел, но как от этого профит получить, не понял. Как по мне, лучше уж локальные стейты с редюсером и контекстом иметь их можно переиспользовать. Но тогда будут перерендеры на каждый чих. Ну хотя бы серверные данные c swr / react-query использовать уже неплохо.
Да легко решается. Тот же принцип единой ответственности по сути. На глобальный стейт должен завязываться и управлять компонент на том максимальном уровне, который с ним работает. Например, компонент, управляющий страницей или крупным блоком на странице. А внутри него уже «глупые компоненты», которые просто принимают параметры и колбэки на определённые события. Это немного противоречит проблеме проп-дриллинга, но на самом деле не так страшен проп-дриллинг, как неверное его использование (неправильная декомпозиция). Контекст тоже не всегда подходит: он ререндерит все подписанные компоненты при изменении своего значения.
Также не надо всё вподряд тащить в глобальный стейт. Например, раскрыт ли визуально тот или иной компонент или показана ли подсказка.
транице.
@@nilsen1879 «медиатор» довольно распыленный паттерн, его можно увидеть во многих паттернах отчасти. Многие путают его с «наблюдателем», но он больше подходит к «шине событий».
Ну получается, 5 правил SOLID свели получается, к одному, что получается, мучились раньше 🤔
Благодарю. Евгений лучший учитель и ментор🎉
Отличны ролик! Огромное спасибо! Очень полезная информация.
3. Даааааа, какая же жиза
Дружище не хочу хейтить, но поработай над своей речью, у тебя слово паразит "получается" в каждом предложении по нескольку раз звучит, слушать тяжело.
Буквально пару видосов назад этим заболел(
Сейчас активно исправляю...
Топ
Евгений Паромов | Front-end, наверное тебе нужно изменить react на svelte, vue, solid.
Первая ошибка реакт разработчика - писать на реакт