Спасибо. Я когда учил реакт еще не было хуков и использовали классовые компоненты. И тогда чтобы оптимизировать компонент нужно было использовать Pure component или в лайфсайкл методе should component update сравнивать явно пропсы, которые хочешь оптимизировать. А с приходом хуков многие подзабили на это или не до конца поняли как все работает. pureComponent этот тот же React.memo по сути. Но вот, что еще можно подчеркнуть, что сами хуки useCalback или useMemo не только для того, чтобы оптимизировать пропсы компонентов обернутых в React.memo, но и для того, чтобы не делать лишние вычисления, так как реакту достаточно сравнить dependencies чтобы определить выполнять ли код внутри или нет, так вот по мимо этого это также экономит ненужные вычисления, и для меня это было всегда существенней, чем React.memo. Но все конечно зависит от конкретно взятой задачи
классное произношение названий на английском! еще твоя интерепретация где есть отдельно реакт в синем прямоугольничке имеет смысл если вспомнить что вообще react состоит из двух частей - react и reactDOM (синий прямоугольник) . белый прямоугольник - react
Вы так классно объясняете, это любовь с первого просмотра!! Наконец то я поняла useCallback и useMemo Планирую посмотреть все ваши видео на канале, это просто алмаз ) Хочется задать вопрос к теме видео, как вы считаете, насколько нужно ударяться в использование memo в контексте избегания перерендеров компонентов? Писать memo для каждого компонента или же у вас есть какие-то примерные критерии, для каких компонентов стоит писать, а для каких нет?
Правильная композиция (организация вложенности) компонентов поможет избежать нежелательных перерисовок приложения. К 'memo' не особо часто приходилось прибегать, так как не каждый компонент имеет смысл оптимизировать. Стараюсь придерживаться идеи "преждевременная оптимизация - корень всех бед". Если надо оптимизировать производительность, то стараюсь правильно организовать композицию между компонентами (так, чтобы максимально сократить количество ре-рендеров). Если такое видится невозможным или бизнес требует быстрее выкатить изменение к проекту, тогда начинаю юзать 'memo'. :)
Спасибо за видео, у меня такой вопрос, разве в версии React 17 и выше не используется вызов __jsx (import { jsx as _jsx } from "react/jsx-runtime";) вместо React.createElement ?
Благодарю! Глянул документацию, не знал что в экосистему React'a внесли такое изменение, мое личное знакомство начиналось с 16 версии, а этот апдейт я пропустил) Получается React.createElement рекомендуют применять только если разработчик сам решит не использовать JSX в своем коде, а функцию _jsx разрешается подставлять только компиляторам Babel или TypeScript (разработчикам нельзя к ней самим напрямую обращаться).
А что есть использовать useMemo внути компонента и в этом же компоненте в return возвращать мемоизированные данные? то есть внутри функции есть memoElement, а в return (...{memoElement}...) Условно const memoElement = useMemo(() => {{users.map...}}, [users])
Согласно документации есть 4 причины использовать useMemo: 1. Skipping expensive recalculations - Чтобы избежать ресурсозатратных вычислений 2. Skipping re-rendering of components - Чтобы избежать повторного ре-рендера компонентов 3. Memoizing a dependency of another Hook - Для мемоизации зависимости другого хука (useEffect, useCallback и т.п.) 4. Memoizing a function - Для мемоизации функции (рекомендуют юзать useCallback, но и с useMemo можно добиться такого же поведения) В видео я разбираю вторую (2) причину. В вашем случае применение useMemo подходит под первую (1) причину. Т.е. в вашем коде вы потенциально избегаете повторного создания массива и применения callback функции метода map на каждый элемент массива. Такого рода мемоизацию я делаю только когда прописываю какие-то страшные вычисления внутри callback-функции, а количество элементов в массиве (users) кажется внушительным:) Немного примитивный подход (без четких цифр и замеров производительности кода), но вот😅
Есть разные курсы, но я их давно снимал, поэтому не совсем такие какими бы я их хотел видеть сейчас) makecs138x.ru/ - курс по CSS makecs50.github.io/web/ - курс по вебу makecs75.ru/ - курс по JS (этот мне нравится, но тоже надо бы когда-нибудь освежить/перезаписать)
@@makecsx Редко встретишь такую качественную подачу материала без воды, у вас большой талант преподавать! Будь у вас полноценный курс по React, купил бы с удовольствием )
А эта тема интересная, для ее покрытия сейчас книжку читаю, так как только в одном проекте приходилось использовать worker и отсюда у меня могут быть пробелы в понимании. Но вся эта функциональность и параллельное выполнение кода предоставляется нам средой исполнения JS. У самого языка вроде нет никаких встроенных функций позволяющих создавать дополнительные потоки выполнения. Вот функциональность предоставляемая средой - это да. Плюс я UA-cam-рекомендации давно отключил через расширение, тогда и ерунды меньше в жизни бывает))
@@makecsx Верно, host среда предоставляет трэды. =) Javascript дополняется host средой. И если говорить про браузеры то одно API, а у ноды своё API. Но параллелизация есть уже прилично давно и там и сям. А эвент луп это всего лишь менеджер задач для рантайма.
очень хорошо, что вы так подробно прошлись по механике работы Реакта и всё разжевали. Первые у кого я встретил такое погружене. Лайк. Подписка
очень крутое объяснение. Вам благодарность от всех джунов!
Просто лучшее объяснение. Благодарю.👍
2 года назад пересмотрел все твои лекции "продвинутый js", которые на канале. Никто так доходчиво не объясняет, спасибо за контент.
просто ты других не слышал )) Нормально объясняет, но слишком быстро говорит. Такие темы для новичков нужно неторопливо объяснять.
@@bjol_Dg я на 1.5 смотрю, вроде норм)
Ulbi: 🗿
Спасибо. Я когда учил реакт еще не было хуков и использовали классовые компоненты. И тогда чтобы оптимизировать компонент нужно было использовать Pure component или в лайфсайкл методе should component update сравнивать явно пропсы, которые хочешь оптимизировать. А с приходом хуков многие подзабили на это или не до конца поняли как все работает. pureComponent этот тот же React.memo по сути. Но вот, что еще можно подчеркнуть, что сами хуки useCalback или useMemo не только для того, чтобы оптимизировать пропсы компонентов обернутых в React.memo, но и для того, чтобы не делать лишние вычисления, так как реакту достаточно сравнить dependencies чтобы определить выполнять ли код внутри или нет, так вот по мимо этого это также экономит ненужные вычисления, и для меня это было всегда существенней, чем React.memo. Но все конечно зависит от конкретно взятой задачи
Спасибо, в голове теперь порядок
Great video, huge thanks
Шикарное объясненье
Хорошо объяснил, но я понял это, только теперь, когда понимаю "контекст" и "замыкания"
Отличный разбор, спасибо
классное произношение названий на английском! еще твоя интерепретация где есть отдельно реакт в синем прямоугольничке имеет смысл если вспомнить что вообще react состоит из двух частей - react и reactDOM (синий прямоугольник) . белый прямоугольник - react
Спасибо за контент👍
Вы так классно объясняете, это любовь с первого просмотра!!
Наконец то я поняла useCallback и useMemo
Планирую посмотреть все ваши видео на канале, это просто алмаз )
Хочется задать вопрос к теме видео, как вы считаете, насколько нужно ударяться в использование memo в контексте избегания перерендеров компонентов? Писать memo для каждого компонента или же у вас есть какие-то примерные критерии, для каких компонентов стоит писать, а для каких нет?
Правильная композиция (организация вложенности) компонентов поможет избежать нежелательных перерисовок приложения. К 'memo' не особо часто приходилось прибегать, так как не каждый компонент имеет смысл оптимизировать. Стараюсь придерживаться идеи "преждевременная оптимизация - корень всех бед". Если надо оптимизировать производительность, то стараюсь правильно организовать композицию между компонентами (так, чтобы максимально сократить количество ре-рендеров). Если такое видится невозможным или бизнес требует быстрее выкатить изменение к проекту, тогда начинаю юзать 'memo'. :)
@@makecsx большое спасибо за развернутый ответ ))
Спасибо за видео, у меня такой вопрос, разве в версии React 17 и выше не используется вызов __jsx (import { jsx as _jsx } from "react/jsx-runtime";) вместо React.createElement ?
Благодарю! Глянул документацию, не знал что в экосистему React'a внесли такое изменение, мое личное знакомство начиналось с 16 версии, а этот апдейт я пропустил) Получается React.createElement рекомендуют применять только если разработчик сам решит не использовать JSX в своем коде, а функцию _jsx разрешается подставлять только компиляторам Babel или TypeScript (разработчикам нельзя к ней самим напрямую обращаться).
А что есть использовать useMemo внути компонента и в этом же компоненте в return возвращать мемоизированные данные? то есть внутри функции есть memoElement, а в return (...{memoElement}...)
Условно const memoElement = useMemo(() => {{users.map...}}, [users])
Согласно документации есть 4 причины использовать useMemo:
1. Skipping expensive recalculations - Чтобы избежать ресурсозатратных вычислений
2. Skipping re-rendering of components - Чтобы избежать повторного ре-рендера компонентов
3. Memoizing a dependency of another Hook - Для мемоизации зависимости другого хука (useEffect, useCallback и т.п.)
4. Memoizing a function - Для мемоизации функции (рекомендуют юзать useCallback, но и с useMemo можно добиться такого же поведения)
В видео я разбираю вторую (2) причину.
В вашем случае применение useMemo подходит под первую (1) причину. Т.е. в вашем коде вы потенциально избегаете повторного создания массива и применения callback функции метода map на каждый элемент массива.
Такого рода мемоизацию я делаю только когда прописываю какие-то страшные вычисления внутри callback-функции, а количество элементов в массиве (users) кажется внушительным:) Немного примитивный подход (без четких цифр и замеров производительности кода), но вот😅
Мне кажется вы забыли упомянуть разницу между примитивами и классами с массивами.
Очень крутое объяснение!
Скажите, у вас есть полные курсы по фронту?
Есть разные курсы, но я их давно снимал, поэтому не совсем такие какими бы я их хотел видеть сейчас)
makecs138x.ru/ - курс по CSS
makecs50.github.io/web/ - курс по вебу
makecs75.ru/ - курс по JS (этот мне нравится, но тоже надо бы когда-нибудь освежить/перезаписать)
@@makecsx Редко встретишь такую качественную подачу материала без воды, у вас большой талант преподавать!
Будь у вас полноценный курс по React, купил бы с удовольствием )
Никакого параллельного выполнения кода??! Скажи это воркерам, кластерам в ноде, атомиксам и тд.. Зачем мне ютуб рекомендует это видео?!)
А эта тема интересная, для ее покрытия сейчас книжку читаю, так как только в одном проекте приходилось использовать worker и отсюда у меня могут быть пробелы в понимании.
Но вся эта функциональность и параллельное выполнение кода предоставляется нам средой исполнения JS. У самого языка вроде нет никаких встроенных функций позволяющих создавать дополнительные потоки выполнения. Вот функциональность предоставляемая средой - это да.
Плюс я UA-cam-рекомендации давно отключил через расширение, тогда и ерунды меньше в жизни бывает))
@@makecsx Верно, host среда предоставляет трэды. =) Javascript дополняется host средой. И если говорить про браузеры то одно API, а у ноды своё API. Но параллелизация есть уже прилично давно и там и сям. А эвент луп это всего лишь менеджер задач для рантайма.