Принцип открытости/закрытости. SOLID для React
ฝัง
- เผยแพร่เมื่อ 15 ต.ค. 2024
- Второй принцип SOLID говорит нам о том, что программные сущности должны быть открыты для расширения, но закрыты для модификации. Разбираемся с тем, что это значит в контексте React-приложений.
Мои курсы по вебу с купонами:
✅ mishanep.com/
📢 Поддержка канала:
/ mishanep
www.tinkoff.ru...
paypal.me/mish...
Было бы чудесно после данного цикла посмотреть ещё и паттерны
Контент огонь, все по понятно, без воды. Подача замечательная. Голос приятный. И темы для видео настолько подходящие, что не передать. Михаил, спасибо за видео, и продолжай в том же духе! Топ 1 канал по фронтенду.
Спасибо за ролик! Таких хороших примеров solid в контексте react еще не встречал! И теперь знаю о библиотеке Chakra UI. Михаил, спасибо!
идеально для тех, кто любит видео формат! Спасибо!
Спасибо! Отличное видео про принципы SOLID
Спасибо за видос, осталось понять как этот InputGroup реализовать самостоятельно)
Отличный урок. Спасибо!
Очень хороший пример open-closed для React'а
Видео было очень полезным! Спасибо большое!
Спасибо за хороший контент. Осознание принципов фундамент для разработки.
как вчера помню смотрел твои уроки по router-dom, а уже пол года работаю, спасибо за качественный видос!
долги ли учился? какие материалы использовал? сколько собесов прошёл?
@@JackShepards Где-то год в Украине нужно потратить чтобы взяли,
всего 12+- собесов с HR, 4-5 тех собесов
Спасибо, ждём продолжения!
Спасибо за полезный контент
спасибо большое за урок, с нетерпением будем ждать буковку L:)
Михаил, спасибо. Отличное видео.
Миша, пилите еще! 👍🏻
жду видосы про следующие принципы
Спасибо! Очень полезно!
благодарю! очень доходчиво и понятно.
Спасибо за контент❤
Спасибо за данный цикл! Хорошие примеры, приятно послушать и напомнить себе, как лучше работать с кодом. Поддержу другие комменты про паттерны, был бы рад послушать о них в вашем изложении
Чудесное видео,жду продолжения
круто, спасибо. Отдельно хотел бы отметить переходы между скринами кусков кода)
то что мне было нужно....мне бы такого ментора и практику правильного написания с ревью, это было бы просто восхитительно
Привет Михаил! Очень классный контент. Пожалуйста сделай видео про git(pull request, merge, branch и тд.) в общем сложные темы в git.
Спасибо)
Отдельное спасибо за знакомство с библиотекой Chakra UI. Теперь писать тэги html и прописывать к ним стили в отдельном css файле просто ... ломает 🤭
Спасибо
Может ли HOC решить эту же проблему? Причем и выглядеть это будет проще. По типу у нас есть базовый инпут и хоки которые навешивают на этот инпут какой то функционал и ui?
а если разница только в стилях, jsx такой же? передавать пропсы, с помощь которых задавать другие классы для тех же элементов?
Здравствуйте, Михаил.
Плейлист хороший, но это видео не понятно по своей сути. Нет примера кода, разбора, есть только ссылка на стороннюю библиотеку. Хотелось бы пример и разбор примера, как в предыдущем видео.
Приведу конкретный критерий "понятного" видео и "не понятного" - после предыдущего видео об SRP я сел и отрефакторил свой код без проблем. После этого видео - нет, я не понял что делать, для каких случаев/компонентов это делать и самое главное как это делать.
Привет Михаил, а про Архитектуру будет что нибудь?:) Там fsd модная тема какая то, вы применяете какую на работе?
Не сыпьте соль. Я мечтаю попасть на проект, где хотя бы solid будет (не только на этапе интервью). Пока пределом мечтаний с точки зрения архитектуры был atomic design. Featured slice мы ковыряли два года назад на одном из проектов, что-то у нас уже было, но в целом под проект целиком дизайн не ложился.
@@mishanep понял, я просто у вас всему научился. Но мне теперь говорят - молодец, сделать можешь, но расширить такое сложно, я вот ищу, от чего отталкнуться что бы грамотно делать, а не просто ляпать. Значит я сейчас принципам солид научусь и будет нормально?:)
@@TheKykp как я могу судить? Вам виднее с какими задачами вы сегодня готовы справляться и с каким качеством. Теория хороша, но бессмысленна без практики.
@@mishanep я даже знаю, что за проект)) Тоже до сих пор обидно, что не влетело. По хорошему, надо сначала выстраивать архитектуру, а потом уже поверх нее всё остальное. Натягивать сову на глобус в обратном порядке - идея так себе, к сожалению. Но реальность почему-то только обратный порядок и предлагает)
ты НЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕРРРРРРРРРРРРРРЕЕЕЕЕЕааааааально круто объясняешь, я прошел весь курс Ивана Петриченко, но твое объеснение, в миллионы раз лучше чем у него
не нарушает ли open closed принцип single responsibility принцип?
Смотря как использовать. Задуманы принципы были так, чтобы использовать их в связке. А значит не должны нарушать друг друга.
Первый был про единую ответственность, и если у нас есть мини-компоненты, которые мы собираем в композицию, то нарушения нет. Есть компонент, чья единственная задача - сделать композицию, есть компоненты со своими мини-задачами.
Большое спасибо за видео! Очень познавательно, интересно и исчерпывающе.
Но, при всем уважении, спонтанные смешки на ровном месте прям сильно режут слух...
Михаил, добрый день! Прости за оффтоп, но поделитесь, пожалуйста, мыслями (хотя бы кратко) о стремительно развивающихся нейросетях. А именно - как адаптироваться, чего нужно остерегаться , чего напротив можно не бояться? Похоже, что frontend это коснулось/коснется в первую очередь.
Уверен, что это тема набила оскомину, но хочется услышать ваше мнение.
И еще - планируете ли вы обучающие ролики, где будете применять новые "нейро-инструменты"?
Почему вы считаете, что фронтенд это коснется в первую очередь?
Со своей стороны замечу, что для создания сайтов десятилетиями существуют простые инструменты, не требующие особых навыков (WordPress, Tilda, wix и ряд nocode решений). У них есть сильные и слабые стороны. То же и с нейросетями. Делают и поддерживают их те же люди, обучают на материалах, которые могут содержать ошибки. Здесь скорее вопрос выбора ниши. За всем не поспеешь, кто-то по классике развивается, кто-то в блокчейн пошел, теперь вот open ai и его аналоги. Я за хорошие хард скиллы в первую очередь. А по необходимости под задачу можно с любым смежным инструментом разобраться.
@@mishanep Сегодня сделал валидацию формы по вашему уроку React hook form. Отрисовал инпуты через .map. И все это в TS. Open AI помог разобраться с типизацией. Но только с правильно поставленными вопросами.
Спасибо, что не оставляете комментарии без ответов!
А сама chakra ui на Docusaurus написана?
Додам ще такий патерн як Prop Getters. В блозі Kent. C. Dodds можна почитати про нього.
А передача в пропси готової JSX-разметки це, власно, Component Composition.
Получается, что все библиотеки вроде chakra ui используют solid. или это не так?
Говорят, любое обобщение ошибочно. За все библиотеки сказать не могу. Но популярные часто так делают.
Михаил, будет ли обновление платного курса по react? Он уже устарел и не хватает TS и полноценного проекта.
Приветствую.
В настоящий момент я не считаю курс устаревшим. Скорее всего возьмусь за обновление с выходом 19й версии. Но без typescript. По TS у меня есть отдельный курс и типизация Реакта там тоже есть. И проекты на всех моих курсах тоже есть.
Может быть я сделаю другой курс, что-то вроде advanced react. Но добавлять TS пререквизитом для тех, кто только знакомится с реактом, я считаю перебором. В advanced уже можно подумать. Но пока новых курсов в планах нет. Возможно во второй половине года, если время будет позволять.
@@mishanep спасибо за ответ!
@@mishanep Спасибо вам большое за все курсы и за материал на канале. Почти всё что пытаюсь гуглить, то что учу сейчас находиться у вас. Но вопрос о курсе по Реакту и вообще по Реакту. Начиная учить Реакт примерно сейчас +- пару месяцев, почти 100% тех кто обучает, преподносит информацию примерно так, что - логика работы функциональных компонентов, ну вот как была на классах и немного подругому, короче говоря новички (и я в том числе:-) ) изучая Реакт хотим изучить так сказать "функциональный Реакт" и расширять свои знания по мере надобности "классовым Реактом", а получается, что большинство туторов, не для новичков, а для тех кто переходит с классов на хуки.. И новичкам приходиться ковырятся в классовых компонентах, что бы понять функциональные.. Это понятно, что классовые много где встречаются, и еще на них много кто пишет...
Добавляя свой код в чужой, для расширения, те же самые пропсы, всё равно происходит модификация. Или смысл в том, что логику мы прописываем где-то отдельно и просто вставляем кусочек лего в пазл, не меняя строки чужого кода?
Здесь, как и везде, надо смотреть по ситуации и не оверинженерить. Если правка минимальна, можно и проп докинуть. Но логика принципа - добавить свой элемент пазла и составить композицию с тем, что было ранее.
Можно и пропсы добавлять при необходимости и код надо местами переписывать.
Просто старый функционал должен продолжать работать.
картинка с роботами же нарушение single responsibility?
Почему вы так считаете?
@@mishanep ведь робот должен заниматься чем то одним судя по названию и посланию из предыдущего ролика.
А тут мы добавляем в него новую функциональность. получается он уже отвечает и за то что бы порезать и за то что бы покрасить.
или я что то не правильно понимаю?
Важно отметить, что принципы проектирования не всегда являются жесткими правилами, и их применение зависит от конкретной ситуации и контекста проекта. Иногда разделение функциональности может быть излишним и привести к избыточности классов. Важно стремиться к достижению баланса между принципами проектирования и понимать, как они могут быть применены в конкретных ситуациях.
Михаил, как относитесь к тестированию реакт приложений? Если мы используем солид мы же ничего не можем сломать, а соответсвенно тесты это бесполезная трата времени
Я крайне положительно отношусь к тестам. Нередко чтение тест-кейсов дает больше представления о реакт-компоненте, нежели чтение кода или (если есть) документации.
От ошибок никто не застрахован.
А некоторые иногда только думают, что пишут на солид))
Непонятно про отличие Расширения и Модификации. Если мы компонент расширяем, это же и есть его модификация. Вот не было у него поддержки пропса, а теперь есть. 🤷
Скорее тут подразумевается что модификации это изменение/удаление какого либо кода который уже написан
@@Кирилл-у3г6ы а как же рефакторинг? Так можно быстро превратить проект в легаси помойку
@@iGotton скорее всего имеется в виду что чтобы добавить фичу не надо трогать старый код, а рефакторинг это наверное само собой
@@shakapaker я не знаю как рефакторить, не трогая код)
@@iGotton к чему это?
спасибо полезная штука