Имхо, автор перемудрил. Перед тем как добавлять мемоизацию, можно попробовать вынести стейт из App в отдельный компонент, изолировать его. Если вынести интут и баттон в отдельный компонент со стейтом `name`, то инпут при введении текста не будет триггерить ре-рендер всего приложения - только при добавлении нового элемента в `names`, а ре-рендер при добавлении в `names` неизбежен, так как это основной стейт приложения, от которого все зависит. В этом сценарии memo для Button не нужен. Потом, добавлять List в memo не имеет смысла, так как при изменение `names`, он будет всегда перерендириваться. Хоть с мемо, хоть без. Таким образом, только обертка ListItem в мемо имеет смысл.
а зачем ListItem оборачивать в memo, если у нас родительский List в твоем случае будет ререндерится только тогда, когда изменяется массив, и по сути и мемо тоже не нужен
Ну я бы инпут и кнопку в отдельный компонент бы вынес, коллбэк бы прокинул (используя useCallback и memo, хотя и то не принципиально было бы, выгоднее его перерисовать будет), useCallback через prev
Изменение пропсов не ведет к перерендерингу, проверьте это сами в песочнице (только стейт родителя не меняйте при этом). То есть перерендеринг возможен только при изменении стейта компонента или одного из его предков (изменение контекста тоже можно считать изменением стейта предка).
Плохая практика используется на строке 30 нельзя добавлять в начало массива элемент очень негативно будут смотреть если так оставить, нужно просто значение поменять местами и тогда сразу решится вопрос с пере рендером списка.
@@svgaryaev сказать что такая логика вносит не понимая для пользователей. Логично добавлять в конец. Ну и если ты хранишь на беке данные то тебе могут отдавать данные по дате создания и проблем не будет.
@@MikhailYan-b8y ничего не логично, есть же оператор unshift, значит добавление элемента в начало списка одна из базовых задач, да, выполняется за O(n) вместо константы для добавления в конец, но та же сортировка по дате создания будет выполняться за O(nlogn), это тестовое задание, какие пользователи, какой бэк?)
@@svgaryaevнадо слать такого заказчика который такую фигню хочет. Использование только push or concat, spread и только в конец массива. Есть такое слово оптимизации, если клиенту такое слово недоступно то нужно обходить его.
насколько в реальном продуктовом проекте нужно вот настолько забодиться о рендерах? Понятно, что если что-то стоит нам слишком "дорого" то да,, но перерендер кнопки - это проблема?
Заботиться не надо до тех пор, пока не увидите просадку производительности. Даже если увидите, сначала надо искать первопричину, а потом уже оптимизировать
а зачем useCallback если инпут uncontroled?
можно ещё убрать перерендер кнопки, передавая в setNames функцию:
setNames((prev) => [newName, ...prev])
рефы в коллбэки можно не передавать, они не реактивны и даже если реф поменяется - useEffect, useCallback и тп не смогут отреагировать
Спасибо, хорошо объясняешь.
Имхо, автор перемудрил.
Перед тем как добавлять мемоизацию, можно попробовать вынести стейт из App в отдельный компонент, изолировать его. Если вынести интут и баттон в отдельный компонент со стейтом `name`, то инпут при введении текста не будет триггерить ре-рендер всего приложения - только при добавлении нового элемента в `names`, а ре-рендер при добавлении в `names` неизбежен, так как это основной стейт приложения, от которого все зависит. В этом сценарии memo для Button не нужен.
Потом, добавлять List в memo не имеет смысла, так как при изменение `names`, он будет всегда перерендириваться. Хоть с мемо, хоть без.
Таким образом, только обертка ListItem в мемо имеет смысл.
а зачем ListItem оборачивать в memo, если у нас родительский List в твоем случае будет ререндерится только тогда, когда изменяется массив, и по сути и мемо тоже не нужен
Ну я бы инпут и кнопку в отдельный компонент бы вынес, коллбэк бы прокинул (используя useCallback и memo, хотя и то не принципиально было бы, выгоднее его перерисовать будет), useCallback через prev
Изменение пропсов не ведет к перерендерингу, проверьте это сами в песочнице (только стейт родителя не меняйте при этом).
То есть перерендеринг возможен только при изменении стейта компонента или одного из его предков (изменение контекста тоже можно считать изменением стейта предка).
Хотелось бы ссылку на исходник или на codesandbox. И так и не ясно почему в итоге кнопка перерендерилась, выходит не до конца убраны перерендеры?
А нельзя просто name убрать из зависимостей?
Плохая практика используется на строке 30 нельзя добавлять в начало массива элемент очень негативно будут смотреть если так оставить, нужно просто значение поменять местами и тогда сразу решится вопрос с пере рендером списка.
а что тогда делать, если нужно добавлять элемент в начало списка, а не в конец?
@@svgaryaev сказать что такая логика вносит не понимая для пользователей. Логично добавлять в конец. Ну и если ты хранишь на беке данные то тебе могут отдавать данные по дате создания и проблем не будет.
@@MikhailYan-b8y ничего не логично, есть же оператор unshift, значит добавление элемента в начало списка одна из базовых задач, да, выполняется за O(n) вместо константы для добавления в конец, но та же сортировка по дате создания будет выполняться за O(nlogn), это тестовое задание, какие пользователи, какой бэк?)
@@svgaryaevнадо слать такого заказчика который такую фигню хочет. Использование только push or concat, spread и только в конец массива. Есть такое слово оптимизации, если клиенту такое слово недоступно то нужно обходить его.
@@MikhailYan-b8y удачи с поисками работы
вот жто хорошее видео. молодец
А f (I) можно для реакт 🚀🧐или моей головой😅
насколько в реальном продуктовом проекте нужно вот настолько забодиться о рендерах? Понятно, что если что-то стоит нам слишком "дорого" то да,, но перерендер кнопки - это проблема?
Да если у вас компоненты списка в которых вы меняете количество и начинается перерендер всех элементов с кнопкой.
больше вреда. там где люди поопытней от этого ушли.
Заботиться не надо до тех пор, пока не увидите просадку производительности. Даже если увидите, сначала надо искать первопричину, а потом уже оптимизировать
На 100%. Если используешь принцип solid и придерживаешься, 90% всей оптимизации уже решаться на месте. Остальные 10% решит fsd методология
дороже будет кнопку в memo обернуть, чем ее перерисовать. И да надо заботиться
а шо так тихо?)
Изменение пропсов не вызывает ререндер
с каких это пор?
Ага, пропсы изменились у компонента, а он не перерендерился, что за бред?
Ребята базу не знают
@@true227пропсы меняются только если поменялся какой то родительский компонент, вот именно это и вызывает перерендер, а не сами пропсы
очень тихо
Заметил уже когда залил) Если буду делать ещё видосы - исправлю.
про inputRef не додумался бы
Кринж