Comments 7
overengineering
GC не вешается от такого "эффективного процесса"?
Выглядит как лишняя обёртка. При необходимости лучше сделать модуль типа arrayUtils.ts, в который вынести пару-тройку замороченных функций обработки массивов. Которые учитывают бизнес-специфику задач.
А пуш-ремув-фильтр можно as is по месту писать.
P.S. "по-новому" пишется через дефис, не пробел.
Уж если выносите логику в кастомный хук, то настоятельно рекомендую оборачивать колбэки в useCallback, так как при вызове, например, в useEffect, увижу красивую надпись в консоли "maximum update depth exceeded"
Колбэки, возвращаемые из хуков, должны иметь стабильную ссылку - а не как здесь
в целом тоже согласен что overengineering и плюс нет типизации проверки на то что default value действительно массив , то есть если я передам что-то отличное от массива , все сломается
во-первых зачем function? контекст не используется, а значит function не нужны и присутствуют по привычке/велению левой пятки.
во-вторых функция update выглядит ужасно. вместо
function update(index, newElement) {
setArray(a => [
...a.slice(0, index),
newElement,
...a.slice(index + 1, a.length),
])
}
можно использовать
function update(index, newElement) {
const newArray = [...array];
array[index] = newElement;
setArray(newArray);
}выглядит компактнее, один спред вместо двух, ноль методов slice. предположу возражение, что "а вот если там, в массиве, ссылочные данные, то мы и в изначальном массиве мутируем элемент со всем его содержимым, так нельзя!" - почему? можно что угодно делать с массивом в стейте - реакт на это никак не отреагирует, пока ссылка на этот массив не поменяется. в общем будто бы рановато автору оригинала показывать миру свои прекрасные хуки
Работа с массивами по-новому. React Custom Hook: useArray