не используют объекты? Ведь если индексировать каждый item по id , то проще хранить и изменять сущность именно в объекте, а не в массиве. Сложность алгоритма будет O(1), а не O(N)(например для пагинации можно просто мержить по id, и даже если что-то пойдёт не так на сервере, чилд будет всего один). А для самого рендера использовать Object.entries. Может есть какие-то подводные камни? Что скажете?
Object.entries() что возвращает?
Вопрос с подвохом 😅 Object.entries(obj).map((item) => item[1])
обход по массиву какую сложность имеет?
Но один раз 👌🏻 а потом useMemo
не понял тебя
Ну пока obj не изменится, будет приходить мемоизированный массив
const array = useMemo(() => Object.entries(obj).map((item) => item[1]), [obj])
ты же читал про порядок значений в массиве, который Object.entries возвращает?
ты в рендере все равно по массиву ходишь, разница?
Его же можно сортировать. Вернее, его все равно нужно сортировать в каком-то порядке.
кто сказал что нужно сортировать всегда?
Работать удобнее с объектом. Селекторы какие-либо строить. Данные получать
Не всегда, но мне нужно 😅 вопрос то не в этом
ты ж понимаешь что при отрисовке списков все равно все сводится к проходу по массиву, потому что (внезапно) это список
Ну хорошо, но например, есть какая-то сущность с количеством 1000 + items, и мы обновляем один из items, с севера приходит ответ и нужно в массиве с 1000+ items найти этот item по id и заменить на тот, что пришёл с сервера, либо если это объект: получить по индексу и обновить. Сложность О(1000+) или О (1). Но да, будет map
так, а как этот пример связан с рендером чилдренов?
Да, рендер из этих items
лады. у тебя объект, как ты его отрисуешь без обхода массива?
Вот я о том и говорю, что будет map по Object.entries, но только после всех изменений.
дык рендер так и работает. изменения -> коммит.
Обсуждают сегодня