#javascript #reactjs #webpack #lazy-loading #code-splitting
#javascript #reactjs #webpack #отложенная загрузка #разделение кода
Вопрос:
Я хочу разделить свой пользовательский интерфейс и логику, чтобы уменьшить размер пакета. Я знаю, что могу отделить логику с headless components помощью подхода или custom hooks и т. Д., Но я также хочу отделить логику от пакета. Я предполагаю, что я могу добиться этого путем отложенной загрузки всей логики и немедленной отправки пользовательского интерфейса.
Я создал пример codesandbox, чтобы продемонстрировать, чего я хочу. Существует компонент, который называется ui/index.js . Он включает в себя компонент под названием <Logic {...props} /> . Logic Компонент отображается, когда enableLogic состояние имеет значение true при первоначальном отображении компонента пользовательского интерфейса. Logic Компонент загружается лениво и ничего не возвращает, null . Единственная цель компонента — визуализировать логику.
const Logic = React.lazy(() =>
import(/* webpackChunkName: "logic" */ "./logic")
);
Мой вопрос в том, что такой подход к простым фиктивным компонентам был бы бессмысленным, но иногда какая-то часть логики большого приложения может быть тяжелой. Интересно, может ли разделение логики и пользовательского интерфейса с помощью такого подхода вызвать у меня какие-либо проблемы? Этот подход используется многими людьми? Существует ли какая-либо библиотека, которая использует такой же подход для разделения логики и пользовательского интерфейса с отложенной загрузкой?
Я считаю, что уменьшение размера пакета для страниц с тяжелой логикой может сократить время, в течение которого пользователи будут видеть страницы.
Вы можете взглянуть на реализацию по ссылке codesandbox прямо здесь.
Codesandbox
Комментарии:
1. Отложенная загрузка компонентов таким образом — очень распространенная вещь в react. Остальная часть вашего codesandbox вызывает большие подозрения — использование
addEventListener/removeEventListener— это огромный WTF.2. Это была просто демонстрация. Детали реализации в Codesandbox на самом деле ничего не значат. Просто хотел привести пример того, что я имею в виду, с некоторым фиктивным кодом. Вы правы, я много раз видел и использовал отложенную загрузку. Но не в такой форме. Отправка логики позже, чем уровень представления компонентов? Я хочу быть уверен, что с этим подходом проблем нет. github.com/theKashey/use-sidecar Эта библиотека использует лучший подход, но довольно сложно понять документацию @Adam
3. Все в react является компонентом. То, что у вашего компонента нет пользовательского интерфейса, не делает его менее компонентом. Если вы хотите отделить свои «логические» компоненты от своих компонентов пользовательского интерфейса, тогда продолжайте. По моему опыту, мне обычно нравится сохранять «тесно связанную логику» (например, взаимодействовать с элементами непосредственно в данном компоненте) в этом компоненте . Их разделение не дает вам никаких преимуществ, если только логика не может быть повторно использована среди множества различных компонентов, и в этом случае это может быть просто перехват, но тогда вы не сможете лениво загрузить его.
4. (продолжение) не усложняйте этот материал, если у вас нет четкого представления об архитектуре, которую вы пытаетесь достичь. Если вы просто «играете», вы узнаете много нового о том, как вы можете лениво загружать вещи, но не используйте это для управления структурой проекта, которую вы собираетесь отправлять.
5. Я знаю, что у меня нет четкого представления или опыта архитектуры, о которой я упоминаю. Вот почему я спрашиваю здесь. Проблема в том, что иногда некоторые компоненты имеют много логики, которую разработчики не могут избежать. Я считаю, что отображение представления перед предоставлением логики в некоторых случаях может увеличить UX, потому что мы отправим меньше кода, поэтому меньше кода для анализа в браузере и увеличим охват кода. Библиотека, которой я поделился, пытается это сделать, и эта статья объясняет, почему dev.to/thekashey/sidecar-for-a-code-splitting-1o8g . Я не хочу отправлять больше кода, который не нужен пользователю для первоначального рендеринга!