Доброго времени суток! Меня зовут Лом-Али Гуржиханов. Frontend Lead в компании Staq. Бывший преподаватель ГГНТУ. Проводил курс по React'у на платформе Geekbrains (gb.ru/users/teachers/fd95d3b3-f945-46b1-864d-2ab9562affc6).
makecs50.github.io/web/ - курс по веб-программированию (2018) makecs75.ru - углубленный курс по JS (2020 )
Ух ты как подробно все и понятно обьясняешь !!! Вроде мелочи по инпутам, но что то новое узнал, что то обновил в памяти. теории сейчас мало хорошей на ютубе, в основном практика одна, в которой не обьясняется все (
Привет! Продолжай снимать ролики, у тебя это получается делать на профессиональном уровне! Очень понятно объясняешь) Несмотря на то, что я уже работаю - все равно было полезно послушать тебя, только газ! От меня лайк, подписка
Кажется я встретил ментора 😄 Я найду и пересмотрю все знания по языку JS которые будут от этого преподавателя. Другие как-то костно язычно объясняют, фиг их поймешь. А тут сразу : "веб приложения - это бешенный интерактив". Все, мне другого объяснения не нужно. Я сразу принял к сведению масштаб и функциональность приложений в вебе. Или "выучить один язык и разрабатывать под все платформы, вот что дает JS, он реально имба". Всееее, сразу кратко, по делу, а главное доходчиво. От души.
JS - простой язык говорят людям вначале а потом на интервью дрочат мозг магией как оно там чего работает внутри - я всегда говорю мне лично пох как оно работает если оно выведет что-то не то я тут же исправлю а ломать себе голову что за хрень происходит внутри это для любителей дебрей жаба-скрипта
тайлвинд с вот этой надстройкой похож если честно на забор на забор. то есть мы сначала пытаемся как-то ускорить разработку используя готовые классы, а потом чтобы это не было столь уродливо ещё городим конструкцию, чтобы не было так уродливо. мне кажется оптимально просто брать по-человечески готовые стили (из-того же тайлвинд или любой другой библы) вставлять в свой файл со стилями в нужные тебе классы и подключать уже красиво класс в код.
А эта тема интересная, для ее покрытия сейчас книжку читаю, так как только в одном проекте приходилось использовать worker и отсюда у меня могут быть пробелы в понимании. Но вся эта функциональность и параллельное выполнение кода предоставляется нам средой исполнения JS. У самого языка вроде нет никаких встроенных функций позволяющих создавать дополнительные потоки выполнения. Вот функциональность предоставляемая средой - это да. Плюс я RU-vid-рекомендации давно отключил через расширение, тогда и ерунды меньше в жизни бывает))
@@makecsx Верно, host среда предоставляет трэды. =) Javascript дополняется host средой. И если говорить про браузеры то одно API, а у ноды своё API. Но параллелизация есть уже прилично давно и там и сям. А эвент луп это всего лишь менеджер задач для рантайма.
Вы так классно объясняете, это любовь с первого просмотра!! Наконец то я поняла useCallback и useMemo Планирую посмотреть все ваши видео на канале, это просто алмаз ) Хочется задать вопрос к теме видео, как вы считаете, насколько нужно ударяться в использование memo в контексте избегания перерендеров компонентов? Писать memo для каждого компонента или же у вас есть какие-то примерные критерии, для каких компонентов стоит писать, а для каких нет?
Правильная композиция (организация вложенности) компонентов поможет избежать нежелательных перерисовок приложения. К 'memo' не особо часто приходилось прибегать, так как не каждый компонент имеет смысл оптимизировать. Стараюсь придерживаться идеи "преждевременная оптимизация - корень всех бед". Если надо оптимизировать производительность, то стараюсь правильно организовать композицию между компонентами (так, чтобы максимально сократить количество ре-рендеров). Если такое видится невозможным или бизнес требует быстрее выкатить изменение к проекту, тогда начинаю юзать 'memo'. :)
А что есть использовать useMemo внути компонента и в этом же компоненте в return возвращать мемоизированные данные? то есть внутри функции есть memoElement, а в return (<div>...{memoElement}...</div>) Условно const memoElement = useMemo(() => {<div>{users.map...}</div>}, [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) кажется внушительным:) Немного примитивный подход (без четких цифр и замеров производительности кода), но вот😅
не всегда стоит запариваться по поводу обновления компонентов, ведь мемоизация не бесплатна и если нет каких-то тяжелых вычислений, то и не стоит париться, проще перерисовать что-то ( в данном примере списки идут и тут нужна мемоизация, но в других случаях нужно думать об этом)
А разве то, что у todolist нет пропсов, и то что проверки не будет, не нивелирует затраты на мемоизацию этого компонента? Да, в памяти реакта будет сохранен готовый результат todolist, но это произойдет единожды, а тосты появляются часто
зачем ещё ставить clsx или className, когда можно написать максимально просто и будет работать быстрее нет поддержки объектов, но к этому можно привыкнуть import { ClassNameValue, twMerge } from "tailwind-merge"; export const cn = (...args: ClassNameValue[]) => { return twMerge(args.filter(Boolean)); };
Соглашусь, выглядит красиво) Объекты мы у себя в команде оставили из-за удобства чтения. Тут кому как нравится) А в плане скорости я даже особой разницы между 'classnames' и 'clsx' не видел, но команда настояла на переход к более оптимизированной либе, а я и не стал спорить). В любом случае, в текущих проектах такой уровень оптимизации мне пока не приходилось применять)
Есть разные курсы, но я их давно снимал, поэтому не совсем такие какими бы я их хотел видеть сейчас) makecs138x.ru/ - курс по CSS makecs50.github.io/web/ - курс по вебу makecs75.ru/ - курс по JS (этот мне нравится, но тоже надо бы когда-нибудь освежить/перезаписать)
@@makecsx Редко встретишь такую качественную подачу материала без воды, у вас большой талант преподавать! Будь у вас полноценный курс по React, купил бы с удовольствием )
классное произношение названий на английском! еще твоя интерепретация где есть отдельно реакт в синем прямоугольничке имеет смысл если вспомнить что вообще react состоит из двух частей - react и reactDOM (синий прямоугольник) . белый прямоугольник - react
В данном примере мы хотим, чтобы уведомление (Toast) отображалось только через 3 секунды после своего монтирования. Поэтому, чтобы таймер запустился после монтирования компонента, мы передаем useEffect'у в качестве первого аргумента функцию, внутри которой вызывается setTimeout, а в качестве второго аргумента - пустой массив. Только благодаря useEffect'у мы можем отследить монтирование и запустить какое-то действие в момент монтирования.
Вы про библиотеку 'classnames'? Когда-то мне коллега по работе посоветовал 'clsx' библиотеку как более производительную альтернативу 'classnames' (бенчмарки: github.com/lukeed/clsx/tree/42354d3b81abd5044f947f93e528351e27e9a12a/bench), поэтому перешел на нее. А у 'tw-merge' другое предназначение - решение коллизий (конфликтов) классов.
Спасибо. Я когда учил реакт еще не было хуков и использовали классовые компоненты. И тогда чтобы оптимизировать компонент нужно было использовать Pure component или в лайфсайкл методе should component update сравнивать явно пропсы, которые хочешь оптимизировать. А с приходом хуков многие подзабили на это или не до конца поняли как все работает. pureComponent этот тот же React.memo по сути. Но вот, что еще можно подчеркнуть, что сами хуки useCalback или useMemo не только для того, чтобы оптимизировать пропсы компонентов обернутых в React.memo, но и для того, чтобы не делать лишние вычисления, так как реакту достаточно сравнить dependencies чтобы определить выполнять ли код внутри или нет, так вот по мимо этого это также экономит ненужные вычисления, и для меня это было всегда существенней, чем React.memo. Но все конечно зависит от конкретно взятой задачи
Спасибо за видео, у меня такой вопрос, разве в версии React 17 и выше не используется вызов __jsx (import { jsx as _jsx } from "react/jsx-runtime";) вместо React.createElement ?
Благодарю! Глянул документацию, не знал что в экосистему React'a внесли такое изменение, мое личное знакомство начиналось с 16 версии, а этот апдейт я пропустил) Получается React.createElement рекомендуют применять только если разработчик сам решит не использовать JSX в своем коде, а функцию _jsx разрешается подставлять только компиляторам Babel или TypeScript (разработчикам нельзя к ней самим напрямую обращаться).
