Шаблон стратегии с возможностью расшатывания деревьев в Typescript

Question

Я пытался создать библиотеку, которая требует от своих потребителей использования определенной c стратегии для каждой цели. Моя текущая архитектура выглядит следующим образом:

[Приложение] -> содержит -> [игрок] -> содержит -> [средство визуализации]

В настоящее время Renderer является интерфейсом, который необходимо заменить для различные платформы:

• Mobile -> использует MobileRenderer
• Web -> использует WebRenderer

У меня есть свобода использования любых пакетов - в настоящее время используется Webpack для приложение и накопительный пакет для библиотеки - и то, чего я мог бы достичь:

Моя библиотека экспортирует интерфейс Player и функцию createPlayer, которая возвращает PlayerInterface. Затем на стороне приложения у меня есть псевдоним Webpack, который разрешает правильную библиотеку платформы на основе входных данных сборки.

Например:

import { createPlayer } from "my-lib";


const player = createPlayer()

Затем мы создаем приложение с

npm run build --platform=web

, в который веб-пакет преобразует импорт my-lib в my-lib/platforms/web, который также содержит экспортированную функцию createPlayer, которая использует правильный рендерер.

Мой вопрос заключается в том, с точки зрения приложения Как мы можем убедиться, что мы импортируем правильный рендерер для каждой платформы во время сборки, позволяя при этом трястись от деревьев (включая только правильные источники)? Я считаю, что использование системы сборки для этого довольно неясно, так как не оставляет четкого следа того, что происходит.

Есть ли лучший способ сделать это?

Бест,

Answer 1

У вас есть пара вариантов. Я бы рекомендовал не использовать переключатель времени компиляции, поскольку для этого необходимо распространять несколько копий вашей библиотеки (что не является идиоматическим c). Однако, если вы действительно хотели это сделать, я бы предложил использовать поле конфигурации ProvidePlugin или resolve.alias веб-пакета, чтобы динамически связывать ваш код с соответствующим средством визуализации во время сборки.

На мой взгляд, более прагматичным c подходом было бы иметь две точки входа в ваше приложение и позволить разработчику выбирать, какую точку входа использовать. Это похоже на то, как react-dom переключается между рендерингом браузера и рендеринга сервера (т. Е. react-dom против react-dom/server):

// index.js

export * from './shared';
export {default as renderer} from './renderers/web';

// mobile/index.js

export * from '../shared';
export {default as renderer} from '../renderers/mobile';

Тогда кто-то, использующий вашу библиотеку, может import {renderer, foo} from 'your-lib' или import {renderer, foo} from 'your-lib/mobile'.

Оба вышеупомянутых подхода работают во время сборки.

Хотя последний подход обычно вынуждает вас выбирать, какую версию библиотеки использовать в вашем коде, вы можете использовать веб-пакет Поле конфигурации resolve.alias для принудительного перенаправления импорта на your-lib на your-lib/mobile.