Comments 53
Писать на VanilaJS, вручную отслеживать изменение состояния компонента, самостоятельно управлять перерисовкой всего и вся внутри — дело непростое. Требуется гораздно больше кода и времени на его поддержку.
Представьте, например, что есть библиотека с чартами, которая работает по принципу, описанному в статье — так почему бы ее не использовать в проекте, если она хорошая. Какая разница программисту, что там внутри, если она работает и много килобайт не отжирает.
Мне всегда казалось что использование Web Components единственное решение, которое на 100% совместимо с чем угодно другим. Зачем ещё кучу всего сверху?
На данный момент нативно Web Components очень мало где поддерживается
C полифилами ситуация лучше
Но полифилы отжирают ~120 кб.
И опять же — в Web Components — внутри все DOM-операции и отслеживание изменений состояния компонента нужно делать ручками, что не так удобно, как в React. Уровень абстракции другой
React нативно вообще нигде не поддерживается и не будет.
Уровень абстракции не хуже. При использовании Polymer есть и биндинги, и возможности рендерить кучу элементов из массива по шаблону, включая реакцию на изменение состояния (в новом проекте я использую Redux вместе с веб-компонентами), и декларативные подписки на события, и многое другое.
Интегрировать это в любой фреймворк весьма просто, ибо там нет ничего кроме родных браузерных событий и свойств элементов. Если ваш фреймворк не может с этим интегрироваться, то стоит подумать о том, чтобы выбросить его в окно.
В противовес попробуйте интегрировать один React компонент в не-React проект — у вас и оверхед React будет похуже оверхеда полифиллов + Polymer, да и без трехэтажной системы сборки не обойтись. А веб-компоненты просто работают. В совершенно любом проекте, так же как в любом проекте работает <div>.
В противовес попробуйте интегрировать один React компонент в не-React проект — у вас и оверхед React будет похуже оверхеда полифиллов + Polymer
В статье я показал, как добиться оверхеда в 20кб.
x-tags, к примеру, тоже 20 КБ, а в браузерах что поддерживают нативно будет вообще 0 (как не крути, таких подавляющее большинство).
При этом будет быстрее и проще, ибо используются нативные интерфейсы.
В описанном способе (насколько я понял) технологический оверхед зашит в каждый компонент, так что 8 компонентов на одной странице по 25 килобайт каждый — это уже солидный жирок. Поправьте, если я ошибаюсь
так что 8 компонентов на одной странице по 25 килобайт каждый
Я предполагаю, что разработчик компонентов даст вам эти 8 компонентов, собранных в одну либу вместе с одним preact-ом.
@salex772 предложил вариант получше https://habrahabr.ru/company/devexpress/blog/316358/?reply_to=9946908#comment_9946898
Я думаю, это вполне реально реализовать
Я предполагаю, что разработчик компонентов даст вам эти 8 компонентов, собранных в одну либу вместе с одним preact-ом.
Это, разумеется, если будет возможность собрать все нужные компоненты в одном месте для такой сборки. В данный момент работаю над проектом, для которого жизненно необходим импорт сторонних компонентов по кросс-домейну вместе с компонентами-зависимостями.
Я думаю, это вполне реально реализовать
Вот тут, да, хотя все равно выглядит сложнее нативного компонента + html imports.
React нативно вообще нигде не поддерживается и не будет.
При использовании Polymer
Изначально речь шла о нативных веб-компонентах. Polymer — это тоже фреймворк и тоже поставляется отдельно от браузера, а значит, сколько-то весит.
Дальше — выбор, на каком фреймворке строить внутренности компонента, это уже дело личных предпочтений каждого, и React (Preact) тут тоже хороший вариант
Оверхед в 20 килобайт......- это прекрасный результат.
нда, на моем первом компьютере 48К было, из них 8 — на видео память и сиcтемные переменные уходило…
эх…
Из своего опыта знаю, что лучше наоборот писать компоненты или какие-то не большие библиотеки на VanilaJS. А для фреймворков писать уже адапторы, если это необходимо.
Хотя ваша мысль мне то де нравится, но как и с любыми решениями такого рода, наверняка есть свои подводные камни.
Я думаю, что создание оберток можно автоматизировать. Например генерить их налету из propTypes
DonutChart.propTypes = {
radius: React.PropTypes.number.isRequired,
holeSize: React.PropTypes.number.isRequired, //0...1
text: React.PropTypes.string.isRequired,
value: React.PropTypes.number.isRequired,
total: React.PropTypes.number.isRequired,
backgroundColor: React.PropTypes.string.isRequired,
valueColor: React.PropTypes.string.isRequired
};
Тогда 100 компонентов (вес их React-овского кода) + 20кб (preact + preact-compat) + десяток килобайт на код, который соберает налету обертки из PropTypes для любого компонента
Про дублирование Preact-а на каждый компонент речи не идёт. Если 100 компонентов в сборке будет — то получится 100 компонентов + один Preact
Возможно вы и правы, но как реализовать динамическую подгрузку preact-а, чтобы компонент не успел до этого поломаться из-за ReferenceError это еще нужно серьезно подумать
А чем плох webpack конфиг externals. Можно задать его как-то так (на примере react):
externals: {
'react': {
root: 'React',
commonjs2: 'react',
commonjs: 'react',
amd: 'react'
}
}в итоге потребитель может использовать несколько подобных универсальных библиотек от разных авторов и никакого дублирования preact. И для обёрток в 1 кб можно для тех же целей, оформить отельную библиотеку.
Лично мне бы не хотелось заставлять программиста, который использует мою библиотеку, подключать какие-то react/preact-ы. Ибо это детали реализации уже.
Но предложенный вами вариант тоже имеет место быть. Многим он подойдет
Внутри компонента может быть свой state, свое внутреннее локальное состояние, которое никуда не денется, пока экземпляр компонента не будет уничтожен.
Если же компонент будет переодически уничтожаться и создаваться заново, и нужно чтобы данные не пропадали, или какой-то другой сложный сценарий использования компонента — тогда придется вынести состояние еще куда-то, но сделать это можно.
Компонент можно написать так, чтобы он поддерживал помимо uncontrolled режима, в котором state внутри создается, еще и controlled режим, при котором state не нужен. В controlled режиме компонент будет дергать колбеки, они будут менять state и отдавать его обратно в props (в аргументы). Так что никакой сериализации. Просто данные можно хранить вне компонента, если нужно
<svg width = {radius * 2 + 'px'} height = {radius * 2 + 'px'}>у вас вся шаблонизация будет проходить на клиенте?
Для таких кроссплатформенных компонент лучше использовать какой-нибудь микромодульный фреймворк, который бы в комплексте с компонентом поставлял лишь минимально необходимый набор микромодулей, а не всю библиотеку целиком.
Кроме того, почему вы не пользуетесь возможностями CSS? Например, мне нужен такой же компонент, но с перла заливкой внутри круга.
В Web Components огромные заморочки с настоящим CSS, поэтому я его не использовал. Но всегда можно взять что-то из аттрибутов(props) и на основе этого выставить style у нужных элементов. Внутри Shadow DOM там как-то не так CSS работает, я мало с этим работал — особо не подскажу.
Насчет микромодулей/микрофреймворка — для меня важна совместимость с React, так что это не мой путь. И я готов заплатить за него 20 лишними килобайтами
А можно какой-нибудь пример такого фреймворка? Просто 20 килобайт — это и так вроде не много, но если можно ещё меньше, то почему нет.
Пример — preact весит всего 3кб. Умеет почти всё тоже самое, что и React, но нет Context-а. Если нужен Context, то подойдёт preact + preact-compat
Это же просто хитрый шаблонизатор, а не фреймворк.
Однако диктует сомнительные ограничения архитектуры, что несколько печалит.
Половинчатое скрытие работы с домом (события вполне себе нативные со всеми вытекающими).
Обновление через формирование целого поддерева, вместо точечных обновлений.
Формирование данных для всего поддерева при каждом обновлении, вместо обновления лишь тех данных, что зависят от исходных.
Смешивание декларативного и императивного описания визуализации.
Необходимые обновления вычисляются внутри библиотеки, на архитектуре приложения это как сказывается?
Если вы про то, что тело метода render компонента пишется как return , то никто вас не заставляет использовать jsx. Если про что-то другое, то поясните мысль, пожалуйста.
События браузера оборачиваются в SyntheticEvent.
Всё равно из него берут target и пошло поехало.
Если вы про то, что тело метода render компонента пишется как return, то никто вас не заставляет использовать jsx.
Без него всё совсем страшненько становится.
Необходимые обновления вычисляются внутри библиотеки, на архитектуре приложения это как сказывается?
Виртуальный дом генерируется заново каждый раз.
Всё равно из него берут target и пошло поехало.
Вы же говорили, что ограничения это сомнительно, а тут полная свобода — хочешь бери, хочешь не бери, хочешь иди-едь, хочешь не иди-едь.
Виртуальный дом генерируется заново каждый раз.
Это деталь реализации библиотеки, на архитектуру приложения она влиять не должна.
Сомнительные ограничения — это сомнительно. Проблема половинчатой абстракции именно в половинчатости. Она вносит дополнительную сложность, не давая бонусов от полной абстракции.
Не должна, но влияет, потому как:
- Если не учитывать детали реализации приложение начинает тупить.
- Невозможно применить некоторые классные архитектурные приёмы. Например — ленивая загрузка и обработка данных.
Я попробовал собрать donut, но там получается всё вместе в минифициованном виде 20 кб, что не сильно лучше варианта с преактом. Но тут и компонент очень простой без особых зависимостей.
React, Web Components, Angular и jQuery — друзья навеки. Универсальные JavaScript-компоненты