Странно что по домашке никто не ответил) Буду спойлерить тогда, а ещё и не правильно могу ответить, так что не кидайте камни) 4 WillUnmount 3 DidMount Компоненты обратные стали для всех последующих после Дмитрия. Ключи уже не играют роль, так как по Reconciliation типы другие. Всё. P.S. если что, я не тестил. Так, догадки...))
Твой канал и мотивирует и демотивирует одновременно;) уже год работаю, пишу на реакте, кажется что многое знаю, но после абсолютно каждого твоего видоса понимаю, что нихрена не знаю;))
Как всегда очень полезное видео! Спасибо! Помню был случай на работе, кто-то в key прописал число, которое рандомно генерируется при каждом рендере. Наверное не стоит говорить, какие лаги это вызывало)
делал я так. я еще дальше пошел в процессе экспериментов, делая кей из значения поля, а как-то случайно вообще одинаковый всем сделал. вот это было весело.
очень круто. Посоветовали этот канал как дополнительный источник информации и я очень рад этому) много информации, которая разжевана и даже ребенок (вряд ли конечно) сможет понять) спасибо за труд
Это наивысшая оценка нашему контенту)) сегодня у нас пришло порядка 200 новых подписчиков, и мы не можем понять, кто поделился ссылкой на нас. Не подскажите?)
Спасибо! Будем продолжать в том же духе) Как раз, час назад закончил записывать аудио дорожку для следующего выпуска в новый плейлист P.S. Делитесь нашими видео с друзьями и коллегами)))
Мне кажется в этой теме нужно сказать пару слов о «reconciliation algorithm» и о том, как теряется производительность на больших массивах. Использовать index можно только на петпроджектах. Но и там все же лучше привыкать к id объекта, которое сами указываем. Чтобы индексы не повторялись при добавлении, можно написать счётчик и прибавлять при каждом добавлении единицу или использовать библиотеку uuid. За видео, лайк.
можно создать просто в папке utils файл типа genId.ts let value = 0; const genId = (prefix = "id_") => prefix + ++value; export default genId; самый простой способ, при этом айдишники никогда не повторятся
Можешь подробно рассказать о чем ты имел в виду? Если что я знаю что такое reconciliation, просто не понял как теряется производительность на больших массивах из-за index в качестве key
Интересно получилось. Я все правильно пояснил перед раскрытием карт, так как понимаю как работает ключ, но в этот же момент я понял что не ответил бы на вопрос - а что же в нем такого, ну или пришлось бы думать как тут можно ответить, ну и второй момент, я осознал какая просадка производительности при использовании индекса в качестве ключа. Хотя опять же, понимаю данный механизм, но воедино мысли собрал только после ролика.
Один момент, который я много где видел - это использование свойства key - для специфической перерисовки компонента. Это выглядит, как костыль. Прям в советах предлагают передать вместо key, к примеру, address, который периодически меняется
У меня как то был интересный случай с key. У нас на совсем широком экране, чуть порядок компонентов менялся. И я присвоил им key, чтобы указывать, что компонент просто изменил позицию, а не вымаунтился :)
Словил артефакт на работе. Исправил, но есть незакрытые моменты. Тут не рассмотрен наверное самый интересный случай, когда в списке попадаются одинаковые ключи, то как ведет себя реакт. И там очень необычное поведение) И как по мне очень нелогичное))
@@it-sin9k мне чисто интересно как это под капотом получается. Это же по сути более глубокое понимание реакта, а значит я плохо знаю реконсилешнс. Это не пробел в знаниях, а пробееееелище (с) Нагиев Пс. Ушел учить реакт )))
я проводил много собеседований, к сожалению отвечает правильно только порядка 15% разрабов, при этом большинство людей, которых я собеседовал писали senior, поэтому у многих есть тут пробел)
Круто! Потратил пол часа, пока разобрался, почему у меня при удалении элемента по индексу, начинается каша. Так что да, твой ролик был бы еще полезнее, если бы я его увидел до. Но свои ошибки обучают, как ничто другое))
Я хочу написать решение домашки, надеюсь не будет спойлером хах. Короче, все элементы под элементом, который мы удалям, а так же и сам элемент. Будут размонтированы и все кроме удаляемого, будут вмонтированы. Т.к. в users роли идут через один. То у всех элементов поменяются типы. Например если сделать одного админа под индексом 4 и удалить элемент с индексом 2. То будет 1 UPDATE с 2 индекса по 3. А вот с 3 на 4 и с 4 на 5 будет опять размонтирование и вмонтирование. Т.к. типы изменились. Короче надо просто помнить, что React эти key использует (не знаю точно как, но представим) в объекте, где ключ это разумеется key, а значение сам компонент. Так вот, когда он в очередной раз проходит по users он смотрит на этот объект и на компонент, который сейчас есть под этим ключом. Он смотрит, если типы разные, то удаляем компонент который был, и вставляем новый. Если типы одинаковые, то просто обновляем пропсы. Если уже пропсы разные то PureComponent обновит компонент.
для генерации уникальных id можно использовать библиотечку uuid. Очень проста в использовании. Она генерирует случайным образом айдишники для элементов. Они уж точно не совпадут. Ну это решение если с бэкенда id не дают )
Тут надо быть осторожным, чтобы uuid не каждый рендер генерил новый id, а только если элемент новый. Иначе будет много анмаунтов и маунтов на каждый рендер :)
@@aleksd286 На сколько я знаю, они не чекают нигде имя use. Все хуки, это просто внутренние функции. А use вроде только eslint чекает. Есть правила такие. Вот видео где исходники хуков я впервые влез: ua-cam.com/video/kcHEWut-DUA/v-deo.html
В таком случае, использовать в качестве ключа Math.random() тоже считается плохой практикой? Получается, что при каждом перерендеринге будет вызываться эта функция и постоянно key будет меняться
Допустим у нас есть 5 юзеров типа { id: number; name: string; } У нас есть родительский контейнер который будет хендлить стейт и удалять элементы, а также есть дочерний PureComponent или memo в зависимости от используемого подхода Допустим мы рендерим c key={index} Если передавать в компонент callback функцию, которая будет удалять элемент по клику мы получим следующее: Последний элемент будет UNMOUNТ, всё как в видео При этом как элементы идущие до удалённого так и те что после будут перерисованы и для всех выполнится DIDUPDATE ***Почему спросите вы? (Возможно и не спросите)*** А дело в том, что callback функцию которая будет удалять элемент нужно вынести отдельно из рендера и обернуть в useCallback, для того, чтобы у нас всегда была мемоизированая функция с одной и той же ссылкой, в этом случае у нас будет выполняться всё как на видео При удалении элемента, все последующие после него будут перерисованы и выполнится DIDUPDATE, а самый последний элемент будет UNMOUNT
Все зависит от ситуации. Если вы делаете скелетон с одинаковыми эллементами, то и index пойдет. А если вы делаете например массив настроек для выпадающего меню, то можно самому константы придумать каждому объекту. Все зависит от ситуации :)
Привет, Синяк. Есть вопросик по поводу функциональных компонентов. Правильно ли я понимаю, что при использовании memo с функциональными компонентами и PureComponent с классовыми от них следует ожидать разное поведение? Или я как то неправильно использую функциональные компоненты? P.S. Я про случай, когда в key проп пихается индекс массива. В функциональных компонентах я использовал useEffect, где также возвращал функцию, и как массив зависимостей передавал проп name.
@@it-sin9k codesandbox.io/s/goofy-pasteur-20xly?file=/src/ Вот код, здесь компонент User - функциональный, Admin - классовый. При использовании индекса массива как key пропа поведение у этих двух компонентов различается. Собственно сам вопрос: такое поведение и следовало ожидать, так как это два разных подхода или я неправильно написал функциональный компонент? Спасибо большое за обратную связь)
Судя по твоему примеру, работают они одинаково. Я думаю, тебе показалось, что они работают по разному из-за того, что ты в return написал console.log с фразой unmount. Хотя этот консоль лог вызовется не только в случае unmount, но и в случае update.
@@it-sin9k Спасибо за уделенное время и разъяснение. Правильно ли я понял, что при обновлении функциональный компонент будет демонтироваться, а затем снова монтироваться, поэтому и будет вызываться возвращаемая функция useEffect? Или мне стоит получше покопаться в документации?
Отличное видео, очень информативное, нужно будет более детально изучить данный вопрос. А то на коммерческих проектах делаю key={Date.now + Math.Random()} - лишь бы отвязался от меня реакт))) Но есть вопрос, допустим я перейду на светлую сторону и не буду использовать индексы, а id попросту нет, есть ли какой-то универсальное решение?
Универсального решения как такого нет. Есть разные приемы, которые мы используем: в случае перечисления сущности с сервера там конечно будет id. Но в случае например пунктов какого-либо меню, которое храним в конфиге в виде массива объектов, там нет id как такового. Поэтому мы на всех проектах договаривались например просто завести дополнительное поле id и придумать туда строковое значение уникальное в рамках этого списка, например: create, edit, delete, copy.
@@it-sin9k Я так понимаю тут нужно разговаривать с архитектором, что бы в будущих проектах избавится от таких проблем. Спасибо огромное за Ваши труды, смотрю все видео, очень познавательный контент!
@@DEDUSHKA_SIM non-keyed вариант (где ключи индексы или ключей вовсе нет) плох при вставке элемента или удалении элемента в середине или начале. Рандом вообще никогда нельзя использовать, он плох всегда.
@@DEDUSHKA_SIM не обязательно разговаривать с архитектором, достаточно написать функцию, которая будет генерировать уникальное поле uniqueKey у объектов массива, а затем использовать его в качестве key
Ну блин, нормальное поведение ключа очевидно, не понятно зачем эту тему жевать? Вообще если я знаю что у меня в массив только добавляются+изменяются значения то конечно использую index. Если добавляются+изменяются+удаляются, то наилучший способ при отсутствии id, создать его произвольно от math.random = `{id: Math.random().toString(16).substring(2), name: "Vasja"}`
Судя по комментариям под видео и людям, которые проходили у меня собеседование многие не знали в деталях, как это работает. То что очевидно для одного, может быть абсолютно не очевидно для другого :) А мои поздравления, если вы хорошо понимаете как это работает)
@@it-sin9k наверно... сам читаю комменты и начинаю понимать почему `npm i is-odd` так популярна. А у самого слезы наворачиваются.. Если пенсионерка вымрет, то мир отупеет...
я точно не изучал этот вопрос. Поэтому поделюсь просто фантазиями)) По идее идет обход дерева компонентов, и оно выполняем всю работу по текущему компоненту и идет дальше. Т.е. условно Dmitriy просто раньше находился в списке, вот его компонент обслужили полностью, а потом перешли к следующему
Спасибо, не вдавался никогда в подробности как он работает, просто придерживаюсь тому, что если с бэка приходит уникальное значение какое-то - то ставить его, если нет то просто index, у меня никогда не возникало с этим проблем, ну если меняться будут то там уже конечно нужно что-то придумать. Вообще классный канал, вроде и знаю реакт и пол года коммерческого, но такие углубленные вещи не сильно понимаю, полезно для развития думаю
Ну чувак, ты крут! Жирный лукос за такой крутой контент 👍
Спасибо! лайк и репост - это самое приятное для нас))
Арчакову лайк за наводку, Синяку лайк за подробнейшее объяснение в видео! :)
@@ShoTHIk 😁
Странно что по домашке никто не ответил)
Буду спойлерить тогда, а ещё и не правильно могу ответить, так что не кидайте камни)
4 WillUnmount
3 DidMount
Компоненты обратные стали для всех последующих после Дмитрия. Ключи уже не играют роль, так как по Reconciliation типы другие. Всё.
P.S. если что, я не тестил. Так, догадки...))
Твой канал и мотивирует и демотивирует одновременно;) уже год работаю, пишу на реакте, кажется что многое знаю, но после абсолютно каждого твоего видоса понимаю, что нихрена не знаю;))
Я уже 10 лет так страдаю))) Вот сейчас для нового ролика сделал исследование про reselect. Открылся он мне вообще с новой стороны)
@@it-sin9kаж смотреть боязно;)
Как всегда очень полезное видео! Спасибо!
Помню был случай на работе, кто-то в key прописал число, которое рандомно генерируется при каждом рендере. Наверное не стоит говорить, какие лаги это вызывало)
Спасибо :)
Да, идея явно так себе)))
делал я так. я еще дальше пошел в процессе экспериментов, делая кей из значения поля, а как-то случайно вообще одинаковый всем сделал. вот это было весело.
Правильно ответил, но вопрос заставил поднапрячься. Хороший вопрос для собесодования. Классная подача материала, пришёл из материалов по SOLID.
Спасибо! Я часто задаю этот вопрос на собеседовании)
только 20% кандидатов отвечают правильно, вот и решил поделиться мыслями
очень круто. Посоветовали этот канал как дополнительный источник информации и я очень рад этому) много информации, которая разжевана и даже ребенок (вряд ли конечно) сможет понять) спасибо за труд
Спасибо за такой крутой отзыв! Очень приятно) на днях кстати выйдет новое видео)
Отличный разбор темы. Посмотрел первое видео на этом канале и решил, что однозначно нужно подписаться. Спасибо за наглядную подачу материала 👍
Это наивысшая оценка нашему контенту))
сегодня у нас пришло порядка 200 новых подписчиков, и мы не можем понять, кто поделился ссылкой на нас. Не подскажите?)
@@it-sin9k я про ваш канал прочитал у Archakov Blog в телеграме - t.me/archakov_im
Вот оно как) а то я уже обыскался) откуда столько людей пришло)) Спасибо!
@@it-sin9k тоже от Арчакова
Полезное видео, пригодилось бы на пару недель раньше на собеседовании :D
в следующий раз будем расторопнее))
Крутой контент делаете! Я про все видео, не только про это. Спасибо!
Спасибо! Будем продолжать в том же духе)
Как раз, час назад закончил записывать аудио дорожку для следующего выпуска в новый плейлист
P.S. Делитесь нашими видео с друзьями и коллегами)))
Чувак, почему ты на столько крут ?))
я только учусь)
материал интересный, задача в конце видео тоже супер, спасибо
Теперь я разбираюсь в ключах!
Спасибо за видосы, случайно тебя нашёл когда искал инфу про попасы и ты реально крут!
ахахах) спасибо) ютуб интересно подкинул нас в разделе попасы))
Мне кажется в этой теме нужно сказать пару слов о «reconciliation algorithm» и о том, как теряется производительность на больших массивах.
Использовать index можно только на петпроджектах. Но и там все же лучше привыкать к id объекта, которое сами указываем.
Чтобы индексы не повторялись при добавлении, можно написать счётчик и прибавлять при каждом добавлении единицу или использовать библиотеку uuid.
За видео, лайк.
можно создать просто в папке utils файл типа genId.ts
let value = 0;
const genId = (prefix = "id_") => prefix + ++value;
export default genId;
самый простой способ, при этом айдишники никогда не повторятся
Можешь подробно рассказать о чем ты имел в виду? Если что я знаю что такое reconciliation, просто не понял как теряется производительность на больших массивах из-за index в качестве key
Wow, первый раз решила узнать что это … и всё поняла 🧐😃👍
Рад слышать! Не зря делал это видео)
Правильно ответил )
красавчик!)
Топ🔥🔥🔥
Во втором примере ошибся, думал, что будут анмаунты и маунты. А вот последний пример вообще супер
Не зря выдумывал примеры)
красиво и наглядно, лайкус
Низкий поклонус ;-)
Давайте больше задачек из собеседований :)
Постараюсь)
Я ваобще кайфую, миллион подписчиков заслуживаешь
Спасибо) вы всегда можете рассказать о нас своим коллегам и поделиться ссылкой в соц сетях)
нам будет очень приятно)
Не знаю что написать, но рассказываешь круто!
Спасибо, что написал! Нам очень приятно!
Спасибо за такие шикарные видосы!
Спасибо!
очень классно объяснил, спасибо)
Интересно получилось. Я все правильно пояснил перед раскрытием карт, так как понимаю как работает ключ, но в этот же момент я понял что не ответил бы на вопрос - а что же в нем такого, ну или пришлось бы думать как тут можно ответить, ну и второй момент, я осознал какая просадка производительности при использовании индекса в качестве ключа. Хотя опять же, понимаю данный механизм, но воедино мысли собрал только после ролика.
круто! значит не зря сделал этот ролик)
Ответил правильно, смотрю дальше... Интересно!
Четко! Спасибо
Один момент, который я много где видел - это использование свойства key - для специфической перерисовки компонента. Это выглядит, как костыль. Прям в советах предлагают передать вместо key, к примеру, address, который периодически меняется
У меня как то был интересный случай с key. У нас на совсем широком экране, чуть порядок компонентов менялся. И я присвоил им key, чтобы указывать, что компонент просто изменил позицию, а не вымаунтился :)
@@it-sin9k 🤔😯
Отличное объяснение ! Спасибо !
Круто очень!!!
да всё же очевидно. просто внимательно читайте react документацию; она очень простая.
круто , круто !!!
Спасибо! Видос классный, но решения нет =) я ожидал что будет какой-то выход из этого )
решение чего именно? я мб уже видео подзабыл)
@@it-sin9k ...что делать с уникальными ключами, например _.uniqueId Lodash нам не подходит потому что мы получаем каждый раз новый айди...
@@viktorkasap так их надо просто генерить 1 раз, а не каждый рендер. Рисуете первый раз элемент, вот заранее для него uniqueId сгенерируйте.
Словил артефакт на работе. Исправил, но есть незакрытые моменты. Тут не рассмотрен наверное самый интересный случай, когда в списке попадаются одинаковые ключи, то как ведет себя реакт. И там очень необычное поведение) И как по мне очень нелогичное))
по идее он ведет себя как сломанное приложение) есть ли смысл рассматривать такие кейсы?
@@it-sin9k мне чисто интересно как это под капотом получается. Это же по сути более глубокое понимание реакта, а значит я плохо знаю реконсилешнс. Это не пробел в знаниях, а пробееееелище (с) Нагиев
Пс. Ушел учить реакт )))
Не понял, а как можно было по другому подумать. Ждал какого то более необычного разрешения.
я проводил много собеседований, к сожалению отвечает правильно только порядка 15% разрабов, при этом большинство людей, которых я собеседовал писали senior, поэтому у многих есть тут пробел)
ответил правильно💪
Красава!)
Круто! Потратил пол часа, пока разобрался, почему у меня при удалении элемента по индексу, начинается каша. Так что да, твой ролик был бы еще полезнее, если бы я его увидел до. Но свои ошибки обучают, как ничто другое))
а так теперь везде использую uniqid, чтобы не забивать себе голову над айдишниками
Гдеж ты раньше был) Таких каналов с гулькин нос)
Добро пожаловать!) у нас много полезного контента)
ЭТО ЛУЧШЕЕЕЕЕ И САМОЕ НАГЛЯДНОЕ !!!!!! ЛАЙК ПОДПИСКА КОЛОКОЛ ЕПТЬ!!! СРАЗУ !!!
Добро пожаловать на канал!)
Perfect 👍
Спасибо
Лучший контент по реакту на ютубе в русском сегменте на одном уровне с UlbiTV !
Высокая оценка, спасибо!)
Я хочу написать решение домашки, надеюсь не будет спойлером хах. Короче, все элементы под элементом, который мы удалям, а так же и сам элемент. Будут размонтированы и все кроме удаляемого, будут вмонтированы. Т.к. в users роли идут через один. То у всех элементов поменяются типы. Например если сделать одного админа под индексом 4 и удалить элемент с индексом 2. То будет 1 UPDATE с 2 индекса по 3. А вот с 3 на 4 и с 4 на 5 будет опять размонтирование и вмонтирование. Т.к. типы изменились. Короче надо просто помнить, что React эти key использует (не знаю точно как, но представим) в объекте, где ключ это разумеется key, а значение сам компонент. Так вот, когда он в очередной раз проходит по users он смотрит на этот объект и на компонент, который сейчас есть под этим ключом. Он смотрит, если типы разные, то удаляем компонент который был, и вставляем новый. Если типы одинаковые, то просто обновляем пропсы. Если уже пропсы разные то PureComponent обновит компонент.
для генерации уникальных id можно использовать библиотечку uuid. Очень проста в использовании. Она генерирует случайным образом айдишники для элементов. Они уж точно не совпадут. Ну это решение если с бэкенда id не дают )
Тут надо быть осторожным, чтобы uuid не каждый рендер генерил новый id, а только если элемент новый. Иначе будет много анмаунтов и маунтов на каждый рендер :)
Единственный канал на ютубе который Реакт так хорошо показывает да еще и в таких дебрях куда никто не лезет
Спасибо! Сам искал такой контент, не нашел. И в итоге решил что надо создавать самому, нечего ждать)
@@it-sin9k интересно было бы послушать как реакт считывает название функций, ищет там startsWith('use') и зажимает данные в памяти
@@aleksd286 имеешь ввиду как работают хуки?
@@it-sin9k да, реакт же смотрит на название фукнций? чтобы определить это хук или нет. Это же не просто конвекция писать хуки через use?
@@aleksd286 На сколько я знаю, они не чекают нигде имя use. Все хуки, это просто внутренние функции. А use вроде только eslint чекает. Есть правила такие. Вот видео где исходники хуков я впервые влез:
ua-cam.com/video/kcHEWut-DUA/v-deo.html
Срываешь покровы с самых сокровенных тайн React
Рад стараться)
да правда крут 👍
Спасибо!
ответил правильно
красава!
Нафига нужен id, если он к чёрту будет меняться?!
React key
дыд апдейт
В таком случае, использовать в качестве ключа Math.random() тоже считается плохой практикой? Получается, что при каждом перерендеринге будет вызываться эта функция и постоянно key будет меняться
Все верно
Допустим у нас есть 5 юзеров типа { id: number; name: string; }
У нас есть родительский контейнер который будет хендлить стейт и удалять элементы, а также есть дочерний PureComponent или memo в зависимости от используемого подхода
Допустим мы рендерим c key={index}
Если передавать в компонент callback функцию, которая будет удалять элемент по клику мы получим следующее:
Последний элемент будет UNMOUNТ, всё как в видео
При этом как элементы идущие до удалённого так и те что после будут перерисованы и для всех выполнится DIDUPDATE
***Почему спросите вы? (Возможно и не спросите)***
А дело в том, что callback функцию которая будет удалять элемент нужно вынести отдельно из рендера и обернуть в useCallback, для того, чтобы у нас всегда была мемоизированая функция с одной и той же ссылкой, в этом случае у нас будет выполняться всё как на видео
При удалении элемента, все последующие после него будут перерисованы и выполнится DIDUPDATE, а самый последний элемент будет UNMOUNT
Всё ли? Не знаю, что это!)
и что делать, если нет айди?) генерировать рендомный каунтер?
Все зависит от ситуации. Если вы делаете скелетон с одинаковыми эллементами, то и index пойдет. А если вы делаете например массив настроек для выпадающего меню, то можно самому константы придумать каждому объекту. Все зависит от ситуации :)
Привет, Синяк. Есть вопросик по поводу функциональных компонентов. Правильно ли я понимаю, что при использовании memo с функциональными компонентами и PureComponent с классовыми от них следует ожидать разное поведение? Или я как то неправильно использую функциональные компоненты? P.S. Я про случай, когда в key проп пихается индекс массива.
В функциональных компонентах я использовал useEffect, где также возвращал функцию, и как массив зависимостей передавал проп name.
честно говоря, я с трудом могу понять ваш кейс, сбросьте код пожалуйста
@@it-sin9k codesandbox.io/s/goofy-pasteur-20xly?file=/src/
Вот код, здесь компонент User - функциональный, Admin - классовый. При использовании индекса массива как key пропа поведение у этих двух компонентов различается. Собственно сам вопрос: такое поведение и следовало ожидать, так как это два разных подхода или я неправильно написал функциональный компонент?
Спасибо большое за обратную связь)
Вечерком гляну)
Судя по твоему примеру, работают они одинаково. Я думаю, тебе показалось, что они работают по разному из-за того, что ты в return написал console.log с фразой unmount. Хотя этот консоль лог вызовется не только в случае unmount, но и в случае update.
@@it-sin9k Спасибо за уделенное время и разъяснение. Правильно ли я понял, что при обновлении функциональный компонент будет демонтироваться, а затем снова монтироваться, поэтому и будет вызываться возвращаемая функция useEffect? Или мне стоит получше покопаться в документации?
Отличное видео, очень информативное, нужно будет более детально изучить данный вопрос. А то на коммерческих проектах делаю key={Date.now + Math.Random()} - лишь бы отвязался от меня реакт))) Но есть вопрос, допустим я перейду на светлую сторону и не буду использовать индексы, а id попросту нет, есть ли какой-то универсальное решение?
Универсального решения как такого нет. Есть разные приемы, которые мы используем: в случае перечисления сущности с сервера там конечно будет id. Но в случае например пунктов какого-либо меню, которое храним в конфиге в виде массива объектов, там нет id как такового. Поэтому мы на всех проектах договаривались например просто завести дополнительное поле id и придумать туда строковое значение уникальное в рамках этого списка, например: create, edit, delete, copy.
@@it-sin9k Я так понимаю тут нужно разговаривать с архитектором, что бы в будущих проектах избавится от таких проблем. Спасибо огромное за Ваши труды, смотрю все видео, очень познавательный контент!
@@DEDUSHKA_SIM non-keyed вариант (где ключи индексы или ключей вовсе нет) плох при вставке элемента или удалении элемента в середине или начале. Рандом вообще никогда нельзя использовать, он плох всегда.
@@DEDUSHKA_SIM не обязательно разговаривать с архитектором, достаточно написать функцию, которая будет генерировать уникальное поле uniqueKey у объектов массива, а затем использовать его в качестве key
uuid, например
Ну блин, нормальное поведение ключа очевидно, не понятно зачем эту тему жевать? Вообще если я знаю что у меня в массив только добавляются+изменяются значения то конечно использую index. Если добавляются+изменяются+удаляются, то наилучший способ при отсутствии id, создать его произвольно от math.random = `{id: Math.random().toString(16).substring(2), name: "Vasja"}`
Судя по комментариям под видео и людям, которые проходили у меня собеседование многие не знали в деталях, как это работает. То что очевидно для одного, может быть абсолютно не очевидно для другого :) А мои поздравления, если вы хорошо понимаете как это работает)
@@it-sin9k наверно... сам читаю комменты и начинаю понимать почему `npm i is-odd` так популярна. А у самого слезы наворачиваются.. Если пенсионерка вымрет, то мир отупеет...
@@eugenex8892 Если люди чего то не знают, это не такая уж трагедия) Может они в чем то другом более прокачены)
+
Почему на 2:25 первым идет will unmount, а не did update? это из-за приоритетов внутри реакта?
я точно не изучал этот вопрос. Поэтому поделюсь просто фантазиями)) По идее идет обход дерева компонентов, и оно выполняем всю работу по текущему компоненту и идет дальше. Т.е. условно Dmitriy просто раньше находился в списке, вот его компонент обслужили полностью, а потом перешли к следующему
я не правильно ответил
Это же хорошо) значит для вас этот контент был крайне полезным и вы прокачались)
@@it-sin9k спасибо с удовольствием просмотрю с тетрадкой все ваши видео! Очень хочу стать крутым разрабом как Вы
Очень лестно) я думаю у вас все получится)
Очень недооцененный канал
Спасибо за такую высокую оценку!
Здравствуйте! На минуте 7:20 мы же видим в обновлённом списке, что Дмитрий нет. Так почему же вы говорите что onMounted Дмитрий?
там вроде как фраза "увидели will unmount Andrey, а не will unmount Dmitry". Т.е. там unmount а не onMounted
Спасибо, не вдавался никогда в подробности как он работает, просто придерживаюсь тому, что если с бэка приходит уникальное значение какое-то - то ставить его, если нет то просто index, у меня никогда не возникало с этим проблем, ну если меняться будут то там уже конечно нужно что-то придумать.
Вообще классный канал, вроде и знаю реакт и пол года коммерческого, но такие углубленные вещи не сильно понимаю, полезно для развития думаю
пока больше всего людей говорили, что канал полезен, когда начинаешь по собеседованиям ходить))