Код-ревью: 8 ошибок в 1 кнопке! Переписываем реальный проект на React.

[@PurpleSchool]

Полное обучение по теме: ➔ Доступный практический курс по React. Вместе напишем 4 комплексных проекта и освоим ключевые навыки работы с Hooks, Redux Toolkit, React Router с поддержкой наставника - purpleschool.ru/course/react-redux Телеграм-канал с советами по разработке: ➔ t.me/purple_code_channel Бесплатные бонусы: ➔ Бесплатная карта развития в разработке под вашу ситуацию - purpleschool.ru/skills ➔ Бесплатный курс «Основы разработки» - purpleschool.ru/course/code-basics ➔ Бесплатный курс «CSS Flexbox» - purpleschool.ru/course/flexbox Полезные видео: 🍿 Вышел React 19 - kzbin.info/www/bejne/j6fbq5mQfN2Eh5Y 🍿 Последний выпуск новостей веб-разработки - kzbin.info/www/bejne/n36pqqSmnryLlbs

[@nightdreams5521]

Хорошо рассказываете. Рефакторинг подобного рода очень полезен. Делайте, пожалуйста, больше. Можно даже подробнее. Я бы с удовольствием посмотрел и часовое видео подобного рода и как можно с более подробным объяснением. Именно такого материала не хватает. Спасибо.

[@PurpleSchool]

@@nightdreams5521 спасибо!

[@romaniksanov8237]

Согласен, код ревью хотелось бы видеть ещё

[@НайтиСебя-у6щ]

Спасибо за урок! Гений, только нервируешь опять😂😂

[@PurpleSchool]

@@НайтиСебя-у6щ 👍

[@АртемМаксимович-й4к]

Я бы добавил что пропс className по сути обязательный для всех компонентов. Потому что бывают ситуации когда в любой компонент нужно будет передать стили для модификации. На счет типизации children вроде как в React.FC он типизируется по дефолту из коробки. Почитав коменты задам риторический вопрос на который каждый выберет свой ответ. Если у вас есть кнопка которая ведёт себя как ссылка, возможно это ссылка которая выглядит как кнопка?)

[@user-uh9sb2kn4c]

интересный контент, вот такого хотелось бы больше

[@PurpleSchool]

@@user-uh9sb2kn4c 👍

[@domestic-wildkat]

Спасибо за видео, полностью согласен со всем сказанным. От себя добавлю, что похожим образом пишется проект на shadcn ui, правда там это все из коробки идет. В прошлом был ярым противником tailwind, сейчас уже довольно долгое время использую его и код получается читаемым и поддерживаемым. Если правильно декомпозировать компоненты, то не будет нагромождения, и всегда можно вынести длинную строчку классов в .module.css.

[@PurpleSchool]

Может тоже когда-нибудь полюблю tailwind)

[@pavelmelnik9952]

@@PurpleSchool лучше не надо.

[@pavelmelnik9952]

у тайлвинда со всеми любовь только безответная

[@АртемМаксимович-й4к]

Tailwind хорош только в CDD. За счет того что можно завернуть портянки атомарных классов в компонент и снаружи его использовать как тег jsx. В классическом подходе это ужасная портянка с классами. Сразу вспоминаю нулевые когда писали все инлайном и в Js вставляли код php и инлайновый css))

[@pavelbely3846]

Хорошее видео! Кажется что здесь и ссылка и кнопка могут выглядят одинаково на UI, в таком случае, как по мне, нет смысла в разделении. Дизайнеры не всегда рисуют переходы на другие страницы как ссылки, в таком случае очень удобно иметь полиморфную кнопку который выглядят как кнопка но может быть ссылкой, 2 в одном и кнопка и ссылка) а если разделить отдельно ссылку и отдельно кнопку с одинаковыми стилями придется постоянно синхронизировать стили в 2ух местах, что не удобно, хоть по солид это и правильно

[@PurpleSchool]

@@pavelbely3846 никто не гарантирует что дизайнер потом не придумает, что при наведении ссылка будет вести себя по-другому)

[@Гооол-й4ч]

Ну я хз, кого это должно волновать. Мол, ну будем менять стили в 2ух местах. Это в принципе проблема дизайна, если у вас ссылка и кнопка выглядят одинаково. Потому что ссылка это тег с одной вполне понятной семантической идеей - нажал => перешёл по какому-то url. И она должна быть визуальна отлична от рандомной кнопки, чтобы пользователь понимал, что сейчас у него откроется другая страница или новое окно. В том числе уникальный дизайн ссылки должен намекать ему на возможности использовать браузерные штучки типа 'открыть в новой вкладке' и тп. Так что в реальном мире у вас никогда не будет идентичного дизайна у кнопки и ссылки. А если будут - значит у вас дизайнер алкаш и нужно решать проблемы дизайна. Если проблемы дизайне не решаются и вы не хотите делать что-либо, кроме как смотреть в макет и верстать на его основании компоненты - просто делаешь так, как делать стоит с точки зрения архитектуры. Тут по-моему вообще не о чём спорить. Тем более у тебя нет гарантий, что всё не произойдёт ровно наоборот, что завтра в голове дизайнера ссылка и кнопка не всплывут, как 2 отдельные сущности и тебе не придётся твой single component дробить на 2, описывая в каждом какие-то особенности. Тут всегда легче сделать лишний раз ctrl c + ctrl v, чем в какой-то момент из 1ой сущности сделать 2 разных, попутно переписав пол проекта, где ты обращался лишь к одному узлу.

[@pavelbely3846]

​@@PurpleSchool а если он поменяет такое же поведение и для кнопки) а если он вообще ничего не поменяет) такие решения, как по мне, принимаются по месту) Из моего опыта очень частый кейс когда есть кнопка и в куче случаев она ведет себя как ссылка, так почему бы ей не быть и кнопкой и ссылкой, если это просто удобно и также расширяемо, так как для дизайнера это все еще кнопка.

[@pavelbely3846]

@@Гооол-й4ч вы говорите, что везде, где есть ссылки, они будут визуально отличаться, а как например здесь на ютубе, кнопка настройки и кнопка short в бургере выглядят одинаково но настройки это линка а шортс это кнопка? тут тоже пьяный дизайнер?

[@Гооол-й4ч]

@@pavelbely3846 ​ я не совсем понимаю, с какого дивайса вы используете приложение и какой конкретно кусок ui описываете. Из чего-то похожего я вижу лишь левую панель на пк версии, где все ссылки выглядят как обычные кнопки. И тут это не столь критично, потому что семантически понятно, что при нажатии будет редирект. Но в любом случае - да, я считаю, что если интуитивно не понятно, что что-либо является ссылкой, это проблема плохого дизайна. И то, что что-то подобное может встретиться на ютубе, меня особо не смущает. Мол, если ты размещаешь ссылки в каком-либо виде в хедере - это мейнстрим, любому пользователю понятно, что при нажатии на текст в хедере ты будешь перенаправлен. Но если ты размещаешь ссылку, окружённую кнопками, учитывая что они между собой визуально не различны - это очевидный кринж. Это просто неудобно и вводит человек в заблуждение. Да у нас в теории есть хайлайт url в левом нижнем углу при наведении, но это не прям чтобы удобно + на мобилке вроде как hover`a нет ).

[@CJIu3eHb]

Насколько надежно передавать className в пропсах для переопределения стилей (12:42)? Ведь он может и не переопределить ничего, если его имя будет выше в выходном css файле. Есть какие-то гарантии, что соберется именно в нужном порядке css? Мне кажется надежнее переопределение делать с помощью style, хотя инлайновые стили обычно всем страшно использовать.

[@PurpleSchool]

@@CJIu3eHb да, тут нужно будет добавлять специфичность переданному классу

[@CJIu3eHb]

@@PurpleSchool Единственный раз так делал, и пришлось городить .myClassname.myClassname {...}. В этом плане в RN гораздо проще - там нет классов, только аналог инлайн. :)

[@Disorrder]

Уважаемые разработчики! Пожалуйста! НИКОГДА не пишите размеры одной буквой l, m, s. Вместо этого лучше использовать двухбуквенные обозначения: xs, sm, md, lg, xl. Так будет меньше коллизий в других местах проекта. Не раз уже натыкался на такой код, который приводил к рефакторингу. Поверьте, искать однобуквенные обозначения гораздо сложнее

[@PurpleSchool]

@@Disorrder 👍

[@vladi4507]

а если в каких то ситуациях нужна кнопка как а в каких то как ?

[@PurpleSchool]

@@vladi4507 сделать 2 компонента

[@vladi4507]

@ но если в проекте tailwind то придеттся делать дубликаты стилей или имеется в виду оборачивать тег button в a ?

[@yuzeyzer7423]

@@vladi4507 Уникальность знаний важнее дубликации кода, в этом случае DRY не уместен. Как и сказал Антон, лучше создать 2 независимых компонента

[@vladi4507]

@@yuzeyzer7423 это только если создавать отдельный css класс со стилями, ибо если делать дубликаты tailwind то будет выглядеть не очень ибо стиль кнопки один и тот же а менять в случае правок нужно будет в двух местах

[@ivankprod]

Лучше сделать через TagName

[@МагомедрасулДжанаев]

Как раз такой очевидный способ определения лучше чем styles[size] и в этом видео показано почему. Ты изменил варианты size на l m s а стили остались старыми

[@PurpleSchool]

@@МагомедрасулДжанаев я же комментирую, что стили для демо менять не буду, чтобы не тратить ваше время

[@robles2145]

Критика о разделении ответственности - есть. А предложения, как решить элегантно проблему - нет. Если в UI ките множество стилей кнопок мы будем это будем все дублировать?) А когда редизайн произойдет, то читать каждую строчку в надежде полной синхронизации?) Или же выносить все стили в отдельный файл, на уровень выше, тем самым, создавая нелепую архитектурную условность? Не вижу проблемы сделать условные типы для пропсов, тем самым разделив ответственность.

[@PurpleSchool]

@@robles2145 да, нужно их стилизовать отдельно. Иначе, когда дизайнер решит переделать ссылки, чтобы они по другому выглядели вы не будете городить костыли. Можете также просто внести их в отдельный общий css модуль, но я бы не рекомендовал

[@ЮрийЗеленский-г5х]

наследование типов от элементов палка о двух концах - 99% того что можно передать никогда передано не будет (всякие `aria` и обработчики событий), а автокомплит они успешно забивают (и это мешает когда не знаешь / не помнишь название нужного пропса или пытаешься понять есть ли нужный пропс вообще)

[@pepperonin]

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

[@PurpleSchool]

Да, но для базовых точно надо

[@ЮрийЗеленский-г5х]

тут возникает вопрос что считать базовым компонентом: - кнопку в которой все что происходит это собирание класнейма? так класнейм можно экспортировать (или функцию что этот класнейм из вариантов собирает) - что-то сложное по типу календаря? можно конечно отнаследоваться от триггера и спредить в него пропсы, но вероятность что таким образом что-то будет передаваться стремится к нулю - что-то промежуточное, где в одном компоненте скомпанованы несколько элементов? по моему опыту скорее появляется необходимость прокидывать стили/класнеймы в несколько элементов, чем необходимость прокинуть фиг пойми что в рутовый/основной я не пытаюсь сказать что наследовать пропсы бесмысленно, но я после размышлений понял что отсутствие автокомплита мне мешает на регулярной основе, а прокидывание редких пропсов происходит слишком редко чтоб оправдывать подобную практику как некое компромисное решение можно все "наследуемые" пропсы элемента закинуть в отдельное поле

[@pepperonin]

@@ЮрийЗеленский-г5х имхо - наследовать нужно если можно заменить стандартным html тегом, если это что-то более сложное и кастомное- чаще не нужно

[@MikoMikocchi]

Как называется ваша тема для VS Code, если не секрет? Все расширения и топы облазил, но похожего ничего не нашёл..

[@uicodeuz]

Тоже ищу

[@PurpleSchool]

PurpleShool Theme

[@ЕвгенийТ-ч8в]

Кажется, что привязываться к конкретным цветам (для примера) в css-переменных вообще не лучшая идея. Сегодня у вас кнопки оранжевые, а завтра дизайнер их перекрасит в зеленые и будет у вас или переменная --prinary-orange со значением 'green' или придется ее переименовывать (что сводит на нет весь профит от использования кастом пропертис).

[@PurpleSchool]

Потому я в видео и говорю про primary названия цветов

[@alekseypavlov2539]

Вот крутая библиотека для создания таких вещей class-variance-authority. Но урок не об этом

[@PurpleSchool]

👍

[@yevheniipolovinchuk5326]

Что вы можете сказать за material UI ? Недавно познакомился с инструментом и пока в полном восторге от возможностей кастомизации. Есть ли какие-то минуса у него?

[@designed6102]

да, у него достаточно много минусов, к примеру: css-in-js, отсутствие контекстов в составных компонентах, к примеру тот же диалог, в него напрямую нужно прокидывать состояние открыт он или нет, то есть не получится просто так взять вставить компонент и он заработает, далее по списку говняное api в некоторых компонентах, если сравнивать с другими ui либами и перечислять можно сколько угодно много, сама по себе либа изжила себя и на рынке есть множество более удобных решений, советую попробовать mantine или же shadcn

[@MaksTrueman]

@@designed6102 сейчас смотрю shadcn. Там буквально в доке криво сверстаны radio button (точка не по центру)

[@yevheniipolovinchuk5326]

@designed6102 спасибо, посмотрю. Я сейчас в поисках инструмента , с которым можно писать стильные компоненты и не писать с нуля css. Раздражает он меня. Material в этом плане показался удобным, но если есть решения менее громоздкие и не столько ресурсозатратные , то буду рад найти и попробовать. Из моего опыта был только bootstrap и material ui

[@nightdreams5521]

@@yevheniipolovinchuk5326 рано или поздно ты придешь к тому, что чистый CSS один из лучших инструментов. UI-библиотеки обычно очень тяжело ложатся на дизайн. За исключением, если дизайнер опирался на определенную библиотеку, при создании макета.

[@111msl111]

Продуктивнее сначала обосновывать какие-то критерии, а потом применять их. А так много «лучше», а кому и почему лучше - непонятно.

[@PurpleSchool]

@@111msl111 кажется я поясняю каждый пункт почему лучше.

[@Disorrder]

Прям подготовили 30 тысяч разработчиков? И все работают? Вот это да! Слабо верится, если честно)

[@PurpleSchool]

Я не говорил что мы подготовили с нуля. Многие проходят курсы для повышения квалификации или хотят изучить определённую тему. А цифры можно легко проверить. Только на Stepik у нас 8000 тех, кто покупал курсы, а это не наша основная платформа. Данные о числе студентов открыты stepik.org/users/purpleschool/profile

[@pro-verstka]

className и props местами поменять надо, иначе при передаче класса перезапишется параметр className и слетят все стили кнопки

[@PurpleSchool]

Нет, мы же вытащили его из ...props

[@Max.Kozlov]

Топ топ топ!

[@PurpleSchool]

❤️

[@0bsess10n]

Ну такое...

[@Black1991Star]

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

[@cepega333]

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

[@pepperonin]

@@cepega333 или уволят сразу, тут 50 на 50)

[@Вбелом-й3з]

ButtonHTMLAttributes - какой кринж. неужели нельзя было написать - ComponentProps ? FC тоже не нужно. раньше в нем чилдрен был. сейчас нет. какие-то методичка старая - года 2018 походу

[@pepperonin]

@@Вбелом-й3з так это ни на что не влияет

[@nass7313]

Объясните пожалуйста поподробнее, в чем кринж и почему не нужен FC стажёру

[@Вбелом-й3з]

@@nass7313 FC не только стажеру не нужен - всем. Устаревшая типизация. Раньше в ней был children, но сейчас его там нет и children приходится отдельно прописывать. Возвращаемый же тип подсветит родитель, если что-то не так. В общем - устаревшая лишняя писанина. Тоже самое типизация пропсов. Есть же специальная короткая запись. Люди старались, придумывали чтобы было удобно.

[@shashi-kf3mw]

​​@@Вбелом-й3зМожно написать FC, у тебя не все компоненты должны иметь доступ у прокидыванию каких то дефолтных пропсов

[@ololololololololololololll]

@@Вбелом-й3з а зачем отдельно прописывать children? для этого есть PropsWithChildren