Реакция: Импорт модулей с деструктуризацией объектов или по отдельности?

Question

В React некоторые пакеты позволяют вам импортировать Компоненты, используя либо отдельное назначение: import Card from "@material-ui/core/Card", либо путем деструктуризации объекта: import { Card } from "@material-ui/core".

Я читал в блоге, что использование синтаксиса деструктурирования объектов может привести к снижению производительности, если ваша среда не имеет надлежащей функции встряхивания деревьев.В результате каждый компонент @material-ui/core импортируется, а не только тот, который вы хотели.

В каких ситуациях использование импорта с деструктуризацией объекта может привести к снижению производительности приложения и насколько это серьезновоздействие будет?Кроме того, в среде, в которой имеет все колокола и свистки, как в конфигурации по умолчанию create-реагировать-приложение, будет ли использование одного поверх другого иметь какую-либо разницу вообще?

Answer 1

Использование внутренней структуры пакета часто не рекомендуется, но это официально действительный в интерфейсе материалов:

import Card from '@material-ui/core/Card';

Чтобы не зависеть от этого и сократить импорт, экспорт на высшем уровнеможет использоваться

import { Card } from "@material-ui/core"

Оба являются взаимозаменяемыми, , пока установка поддерживает встряхивание дерева .В случае, если неиспользованный экспорт верхнего уровня может быть потрясен деревом, первый вариант предпочтительнее.В противном случае второй вариант предпочтительнее, он гарантирует, что неиспользуемый импорт пакетов не будет включен в комплект.

create-реагировать-приложение использует конфигурацию Webpack, которая поддерживает встряхивание дерева и может извлечь выгоду из второго варианта.

Answer 2

Загрузка дополнительного кода, такого как многочисленные компоненты из material-ui, который вам может не понадобиться, оказывает два основных влияния на производительность: время загрузки и время выполнения.

Время загрузки простое: ваш файл JS) больше, поэтому загрузка занимает больше времени, особенно при более медленных соединениях, таких как мобильные.Правильно уменьшать JS с помощью таких механизмов, как встряхивание дерева, - это всегда хорошая идея.

Время выполнения немного менее очевидно, но также имеет аналогичный эффект, на этот раз для браузеров с меньшей доступной вычислительной мощностью - опять же, прежде всегомобильный.Даже если компоненты никогда не используются, браузер все равно должен анализировать и выполнять исходный код и извлекать его в память.На вашем настольном компьютере с мощным процессором и большим объемом памяти вы, вероятно, никогда не заметите разницы, но на более медленном / старом компьютере или мобильном устройстве вы можете заметить небольшую задержку даже после завершения загрузки файлов по мере их обработки.

Предполагая, что у вашего инструмента сборки правильно работает встряхивание дерева, мое мнение, как правило, примерно эквивалентно.Инструмент сборки не будет включать неиспользуемые компоненты в скомпилированный JS, поэтому он не должен влиять ни на загрузку, ни на время выполнения.