Веб-пакет - предотвращение дублирования файлов с помощью разделения кода веб-пакета и реактивной загрузки

Question

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

Я столкнулся с чем-то, что я считаю довольно большой проблемой, возьмем этот пример:

const FirstChild = Loadable({
    loader: () => import('some/file/path/FirstChild.jsx') 
});
const SecondChild = Loadable({
    loader: () => import('some/file/path/SecondChild.jsx') 
});
const ParentComponent = () => (
    <div>
        <FirstChild />
        <SecondChild />
    </div>
);

, где FirstChild.jsx и SecondChild.jsx импортируют один и тот же сервис:

import MyService from 'some/file/path/my.service.js';

При связывании этого с веб-пакетом мы получаем 3 файла:

• Основной комплект(включает родительский компонент)
• Пакет FirstChild (включает MyService)
• Пакет SecondChild (также включает MyService)

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

Я понимаю, что сервис здесь может быть перемещен «на верхний уровень» в ParentComponent и, возможно, передан в качестве опоры каждому компоненту, но кажется, что он разрушает архитектуруэтот веб-пакет имеет место в первую очередь - чтобы иметь возможность импортировать все, что нам нужно, куда нам нужно, и он создает только одну ссылку.Это также может быть проблематично, если у вас есть много вложенных компонентов, которые все должны импортировать различные сервисы и другие компоненты.

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

Есть мысли по этому поводу?Спасибо!

Answer 1

Собираюсь ответить на мой собственный вопрос по этому вопросу.

Обнаружил, что:

• Неважно, что MyService.js заканчивается на выходе каждого чанка.Webpack достаточно умен, чтобы загружать только первый экземпляр MyService, который он находит, и использует только одну ссылку для этого.Это означает, что если FirstChild сначала загрузит MyService, то SecondChild также будет использовать тот же MyService, который был загружен FirstChild, а его копия MyService будет просто игнорироваться.
• ФайлыИмпорт внутри динамического импорта можно разделить вручную, добавив небольшую конфигурацию Webpack и сопоставление имени файла (спасибо @AndriiGolubenko за указание на правильное направление), мы просто получаем странные структуры папок и имена файлов.Например, код для MyService.js в этом случае может оказаться в виде фрагмента, подобного services~FirstChild/SecondChild/SecondChild.js - что не очень удобно для отладки, но я предполагаю, что Webpack ссылается на его импорт.

    optimization: {
        splitChunks: {
           cacheGroups: {
                services: {
                    test: /\.service.js$/,
                    enforce: true
                }
            }
        }
    },

Пожалуйста, дайте мне знать, если что-то из этого не так, или вы найдете другие интересные моменты о разделении кода + веб-пакет.