Хорошее видео. Я до всего этого сам допер. И приятно что в этом видео сделано также как и у меня на своих проектах - значит ход мыслей в нужном направлении)). Помню видео было на канале по Vue где чел сказал что логика приложения и её реализация не должны пересекаться, т.е. в данном случае видно что в компоненте есть сортировка и фильтрация - логики, но их реализаций в компоненте нет и все они находится в кастомных хуках. Единственное о чем не все говорят что кастомный хук отличается от обычной функции тем что его название начинается с use (например useFilter). Если вы не напишите use то вы не сможете использовать нативные хуки внутри такой функции. Может быть это очевидно, но может кому то будет полезно... мне бы было в свое время))
Отличное объяснение! Спасибо большое) С хоками теперь все понятно. Только я считаю, что они скорее не про разделение логики, их основной смысл в возможности слияния двух и более похожих, но разных компонентов. Возможно не прав, попробую понять на практике
Здесь бэкенд тогда потребуется. Напрямую с фронта слать в платежную систему запросы с секретными ключами как минимум небезопасно. Как минимум, NextJS. Я подумаю в эту сторону.
Было здорово увидеть видео с реализацией кастомных хуков, которые Вы часто в работе используете, мне как человеку на время забросившему реакт для работы на ангуляре, нужно в темпе поменять майндсет с сервисов на хуки)
Хорошее видео, спасибо! С Хуками пример выглядит более элегантно, Хоки я бы мб использовал как декораторы в несте: авторизация, DI, логирование, гварды и тд
Мы писали хуки когда это не было мейнстримом 😅 Только они называли хелперсами 😉 Спасибо за видео. Очень наглядно. Добавлю ссылочку в пособие для новобранцев.
Отличное видео! Спасибо! Если кому интересно: есть ещё классный подход 'Контейнерные и презентационные компоненты', как собрат и конкурент НОС-у. Как по мне он более простой и читаемый.
недавно решал подобную задачу на кастомном хуке. жаль что не удосужился поискать и не встретил это видео. так же сначала хотел с хок делать. но все же на хуке сделал.
В примерах в видео всегда код который хорошо вынести в отдельный хук, который потом можно переиспользовать. А вот что делать с куском императивного кода, который ты понимаешь, что точно нигде больше использоваться не будет? Все равно вынести в хук? А вариант просто создать какой то файл, что то типа XxxModel и в него выносить куски такого кода, который невозможно переиспользовать, просто что бы создать слой абстракции, нормальный, как считаете?
Мы в проектах создаём много узкоспецифичных хуков, которые только в 1 компоненте и используются. Здесь вопрос их хранения. Переспользуемые в общей папке, как на видео. Узкие - в папке с компонентом (обычно 1 компонент - 1 папка, чтобы хранить там тесты, стили и прочие штуковины).
Михаил, спасибо за видео. Скажите пожалуйста, если используется redux, стоит ли выносить логику связанную с useSelectror и useDispatch в кастомные хуки для разделения? Если да, то где лучше эти хуки подключать? Там где они непосредственно требуются или в родительском компоненте и передавать значения из хука по пропсам детям?
Что касается места использования, то по ситуации. Если данные нужны одному дочернему компоненту, то в нем и подключать хуки. Если это десяток дочерних компонентов, нуждающихся в одной и той же логике, лучше через пропсы от родителя.
Кстати запись типа export default withApp(App); в компонентах тоже много где запрещена, так ты привязываешь компонент к конкретному контейнеру. Теряется сам смысл использования хоков. Вместо этого используют вложения как у html тегов.
Согласен. Но и с хуками получилось, что компонент как был с логикой, так и остался, просто теперь она вынесена в хуки. По идее, чтобы сделать чисто presentational компонент, нужно создать компонент-контейнер (хок?), который будет использовать те самые хуки и рендерить презентационный компонент, передавая ему необходимые пропсы. Тем не менее, как демонстрация различия хоков от хуков, видео годное 👌
Михаил, уже говорил спасибо за потрясающе полезные уроки. Кажется ютуб решил удалить тот коммент. Так что еще раз повторю. Так же хочу сказать, что возникла проблема. Приведу решение для тех у кого тоже самое. Не знаю что конкретно повлияло, возможно новая версия реакта. Сделал Hoc-компонент, по примеру WithApp на 8.50 мин. Так он работал, но при попытке использовать useState выдал ошибку React Hook "useState" cannot be called inside a callback. Нашел решение Вкратце, вместо withapp(Component) { сделал withapp(Component) => { , + вместо return function (props) { сделал return function Comp(props) { . Хотел привести ссылки, но ютуб просто удаляет комментарии, возможно из-за них. Поэтому без меня найдете.
Это дело вкуса и обычно решается на уровне команды. В целом если папка называется hooks, то логично что там хранятся только хуки и доп префикс в названии файла можно опустить.
почему ни слова про перформанс ) мне кажется, хоки будут обновляться чаще, уменьшая производительность, именно по этой причине от них многоие отказываются
Не думаю, что хук фильтра должен предлагать настройку задержки. При желании можно добавить и такую настройку с дефолтным значением. Как бы вы реализовали дебаунс? И в чем конкретно видете нарушение? Фильтр фильтрует, дебаунс реализует задержку. По-моему каждый занимается своим единственным делом.
@@mishanep Например я подключаю ваш хук для фильтрации в свое приложение , я не могу изменить код хука и увидеть код хука . Но и задержку тоже не хочу,что делать?) Хук задержки я бы вызывал в компоненте.
@@user-iu7ll2wx4x любое приложение старается быть консистентным, поэтому я с трудом представляю себе ситуацию, где в одной части приложения фильтр нужен с задержкой, а в другой - без. И сама задержка вероятнее всего будет всегда одинаковой, поэтому настройка и не требуется. Другой разговор, если мы пишем свою библиотеку хуков общего пользования, тогда имеет смысл поработать над гибкостью. Но это более сложная тема.
Лучший пример использования кастомных хуков, что я видел...
спасибо за самые лучшие, бесплатные, красивые, изящные и понятные уроки в интернете! ❤
Спасибо, Михаил, классный контент, легкое доходчивое объяснение, рад что нашел ваш канал))
Благодарю, топовый контент, то чего не хватает.
Разделение логики React, hooks, hoc, кастомные хуки
Михаил, благодарю вас
ничего лучше не видел, коротко, просто, информативно, позитивно
Не устаю восхищаться подачей материала. Великолепно! Спасибо за труд!
Спасибо за позитив :)
Мне как раз надо сделать фильтрацию билетов по 4 параметрам (checkbox). Это видео - то что меня спасёт :-)
Спасибо, Михаил, пригодились и мне твои знания! Дай Бог благ земных!
Классный пример на HOC и custom hooks!
Нравится доходчивое объяснение, смотрю уже не первое видео. Спасибо!
Хорошее видео. Я до всего этого сам допер. И приятно что в этом видео сделано также как и у меня на своих проектах - значит ход мыслей в нужном направлении)). Помню видео было на канале по Vue где чел сказал что логика приложения и её реализация не должны пересекаться, т.е. в данном случае видно что в компоненте есть сортировка и фильтрация - логики, но их реализаций в компоненте нет и все они находится в кастомных хуках. Единственное о чем не все говорят что кастомный хук отличается от обычной функции тем что его название начинается с use (например useFilter). Если вы не напишите use то вы не сможете использовать нативные хуки внутри такой функции. Может быть это очевидно, но может кому то будет полезно... мне бы было в свое время))
Спасибо за урок! Было действительно полезно!
Просто и наглядно. Спасибо, Михаил!
Отличное объяснение! Спасибо большое) С хоками теперь все понятно. Только я считаю, что они скорее не про разделение логики, их основной смысл в возможности слияния двух и более похожих, но разных компонентов. Возможно не прав, попробую понять на практике
спасибо вам большое за такой полезный контент. То что вы делаете, для нас неоценимо.
Вы просто лучший! Спасибо за вашу работу.
Спасибо , сделайте видео по интеграции платёжной системы ✊ тема очень интересная
Здесь бэкенд тогда потребуется. Напрямую с фронта слать в платежную систему запросы с секретными ключами как минимум небезопасно. Как минимум, NextJS. Я подумаю в эту сторону.
@@mishanep было бы интересно посмотреть!
спасибо большое, Михаил! прям идеально вовремя ютубчик подбросил это видео
отличное видео, спасибо большое за ваш труд
Было здорово увидеть видео с реализацией кастомных хуков, которые Вы часто в работе используете, мне как человеку на время забросившему реакт для работы на ангуляре, нужно в темпе поменять майндсет с сервисов на хуки)
Спасибо! Очень доступно и интересно.
Хорошее видео, спасибо!
С Хуками пример выглядит более элегантно, Хоки я бы мб использовал как декораторы в несте: авторизация, DI, логирование, гварды и тд
Благодарю. Полезный материал 👍
Спасибо! Как всегда, очень актуальные ролики!
13:51, интересная композиция оберток... 👍
Мы писали хуки когда это не было мейнстримом 😅 Только они называли хелперсами 😉
Спасибо за видео. Очень наглядно. Добавлю ссылочку в пособие для новобранцев.
новобранцы не потянут, слишком быстро тараторит и мелькает все.
Отличное видео! Спасибо!
Если кому интересно: есть ещё классный подход 'Контейнерные и презентационные компоненты', как собрат и конкурент НОС-у. Как по мне он более простой и читаемый.
Спасибо большое
Супер! Спасибо!
Спасибо за видео! Актуальную тему разбираете)
недавно решал подобную задачу на кастомном хуке. жаль что не удосужился поискать и не встретил это видео. так же сначала хотел с хок делать. но все же на хуке сделал.
Спасибо за разбор, информативно
Надеюсь хотя бы частично ответил на ваш вопрос про умные/глупые компоненты.
@@mishanep да, вполне
Спасибо.
Nice
В примерах в видео всегда код который хорошо вынести в отдельный хук, который потом можно переиспользовать.
А вот что делать с куском императивного кода, который ты понимаешь, что точно нигде больше использоваться не будет? Все равно вынести в хук? А вариант просто создать какой то файл, что то типа XxxModel и в него выносить куски такого кода, который невозможно переиспользовать, просто что бы создать слой абстракции, нормальный, как считаете?
Мы в проектах создаём много узкоспецифичных хуков, которые только в 1 компоненте и используются. Здесь вопрос их хранения. Переспользуемые в общей папке, как на видео. Узкие - в папке с компонентом (обычно 1 компонент - 1 папка, чтобы хранить там тесты, стили и прочие штуковины).
Хуки топ, с Хок выглядит страшнее чем было до
🕺🕺🕺
Сделайте пожалуйста про разделение логики с Apollo.
Михаил, спасибо за видео. Скажите пожалуйста, если используется redux, стоит ли выносить логику связанную с useSelectror и useDispatch в кастомные хуки для разделения? Если да, то где лучше эти хуки подключать? Там где они непосредственно требуются или в родительском компоненте и передавать значения из хука по пропсам детям?
Здравствуйте.
Да, имеет смысл выносить. И в кастомные хуки подключать хуки редакса, возвращая в компонент готовые данные и методы.
Что касается места использования, то по ситуации. Если данные нужны одному дочернему компоненту, то в нем и подключать хуки. Если это десяток дочерних компонентов, нуждающихся в одной и той же логике, лучше через пропсы от родителя.
Кстати запись типа export default withApp(App); в компонентах тоже много где запрещена, так ты привязываешь компонент к конкретному контейнеру. Теряется сам смысл использования хоков. Вместо этого используют вложения как у html тегов.
Согласен. Но и с хуками получилось, что компонент как был с логикой, так и остался, просто теперь она вынесена в хуки.
По идее, чтобы сделать чисто presentational компонент, нужно создать компонент-контейнер (хок?), который будет использовать те самые хуки и рендерить презентационный компонент, передавая ему необходимые пропсы.
Тем не менее, как демонстрация различия хоков от хуков, видео годное 👌
Здравствуйте можете подсказать что за кеширования и зачем оно здесь?)
Михаил, уже говорил спасибо за потрясающе полезные уроки. Кажется ютуб решил удалить тот коммент. Так что еще раз повторю.
Так же хочу сказать, что возникла проблема. Приведу решение для тех у кого тоже самое.
Не знаю что конкретно повлияло, возможно новая версия реакта. Сделал Hoc-компонент, по примеру WithApp на 8.50 мин.
Так он работал, но при попытке использовать useState выдал ошибку
React Hook "useState" cannot be called inside a callback. Нашел решение
Вкратце, вместо withapp(Component) { сделал withapp(Component) => { , + вместо return function (props) { сделал return function Comp(props) { .
Хотел привести ссылки, но ютуб просто удаляет комментарии, возможно из-за них. Поэтому без меня найдете.
Просьба: объяснить на примерах что класть в Redux, а что нет
как говорит наш мессия Дэн Абрамов - ничего 😂
разве нет рекомендации не использовать хук useEffect внутри hoc?
Сильно! А почему названия файлов с хуками не имеют префикса "use"? на мой взгляд удобно, когда файлы именуются так же, как и экспортируемые функции...
Это дело вкуса и обычно решается на уровне команды. В целом если папка называется hooks, то логично что там хранятся только хуки и доп префикс в названии файла можно опустить.
Спасибо огромное за информативный ролик ! Планируется ли в будущем видео по jest тестированию и React Testing Library ?
Здравствуйте.
На канале уже есть видео по React testing library и видео по end 2 end тестированию с Cypress
@@mishanep Увидел, спасибо тебе за такой бомбезный контент
почему ни слова про перформанс ) мне кажется, хоки будут обновляться чаще, уменьшая производительность, именно по этой причине от них многоие отказываются
Справедливо. Как минимум, каждый хок - это дополнительный узел в виртуальном доме.
Спасибо за видео, но зря дебаунс смешали с фильтрами - вы нарушили единую ответственность + хук фильтра ничего не говорит о задержке
Не думаю, что хук фильтра должен предлагать настройку задержки. При желании можно добавить и такую настройку с дефолтным значением.
Как бы вы реализовали дебаунс? И в чем конкретно видете нарушение? Фильтр фильтрует, дебаунс реализует задержку. По-моему каждый занимается своим единственным делом.
@@mishanep Например я подключаю ваш хук для фильтрации в свое приложение , я не могу изменить код хука и увидеть код хука . Но и задержку тоже не хочу,что делать?) Хук задержки я бы вызывал в компоненте.
@@user-iu7ll2wx4x любое приложение старается быть консистентным, поэтому я с трудом представляю себе ситуацию, где в одной части приложения фильтр нужен с задержкой, а в другой - без. И сама задержка вероятнее всего будет всегда одинаковой, поэтому настройка и не требуется.
Другой разговор, если мы пишем свою библиотеку хуков общего пользования, тогда имеет смысл поработать над гибкостью. Но это более сложная тема.
Очень жаль, что вы проиграли Магнусу в матче за шахматную корону:(
Мои коллеги по работе больше любили вспоминать вывеску моей игры против корейского гроссмейстера Нихуа.
"Смысла немного" - его вообще нет.
Спасибо!