Давайте сначала проясним ситуацию. В настоящее время я работаю над продуктом с настраиваемой частью для каждого клиента и основной частью, в которой у вас есть ядро приложения. Для клиентской части мы реализовали что-то вроде nylas mail (https://nylas.github.io/nylas-mail/guides/React.html). Клиент может регистрировать некоторые компоненты, меняя тему и т. Д. c ... Возможно получить доступ к некоторым функциям из ядра через определенный объект c, определенный внутри глобальной переменной. Клиентская часть построена на его стороне, тогда все компоненты регистрируются во время выполнения. Он работает очень хорошо, в большинстве случаев этого достаточно для клиентов.
Но в последнее время мы столкнулись с проблемой. Некоторые клиенты хотят еще более c и более c функций. И невозможно просто сказать: «Нет, теперь это возможно». Мы должны найти способ реализовать и иметь что-то более гибкое. Поэтому в настоящее время мы ищем лучшее решение для этого. Конечно, с текущей реализацией мы могли бы сделать это и сказать: «Давайте просто продолжим добавлять некоторые функции в глобальный объект из ядра». Но иногда это очень специфическая c вещь, и другая проблема состоит в том, что постоянное добавление новых возможностей становится несостоятельным.
Другая проблема текущей ситуации заключается в том, что все зависимости дублируются в ядре и клиентской части и внутри клиентской части (просто React передается как глобальная переменная). В этой ситуации у нас нет доступа к основному DOM внутри клиентской части (например, нет доступа ко всем провайдерам). А это очень проблематично c. Например, вы хотите выполнить перетаскивание между компонентом внутри ядра и другим внутри клиента. Это невозможно ...
Сейчас цель состоит в том, чтобы найти лучшее решение, в котором мы могли бы легко добавить очень конкретный c код, имея при этом что-то поддерживаемое в течение следующих нескольких лет.
Первое Возможный способ реализации, который может заключаться в непосредственном внедрении клиентского кода во время сборки.
- Первой возможностью может быть добавление клиента как часть ядра (как зависимости) или наоборот и сборка все вместе.
- Другим решением может быть замена компонентов. React работает как компоненты внутри дерева, так почему бы не сказать хорошо, давайте определим определенные c компоненты внутри клиентской части, а затем добавим / заменим их во время сборки, возможно, определенным c плагином babel. Это может быть интересно, но что произойдет, если мы скоро перейдем на TypeScript ...?
Я не нашел много документации, в которой говорится о проблемах c для внедрения кода во время сборки .
Не стесняйтесь поделиться своими отзывами, чем вы сейчас пользуетесь, вашей идеей и т.д. c ...