Комментарии 64
Дизайн и набор компонентов ATOL
1. Использование свойства class
Можно использовать
export {className as class}Пример: svelte.dev/repl/238798df2fbf42668cce12c23e72459f?version=3.18.1
- Порталы
Могу предложить реализацию портала через экшены(ака действия, ака actions). Элегантнее получится.
<script>
let show = false;
function portalAction(node,parent){
parent = parent || document.body;
parent.appendChild(node);
}
</script>
<button on:click={()=>show = !show}>show</button>
{#if show}
<div use:portalAction>content</div>
{/if}Навешиваем экшен portalAction на элементы, которые должны уходить в "портал" при помощи директивы use:. Ещё можно указать в параметре экшена родительский элемент для перемещаемой ноды — use:portalAction={parentNode}. При монтировании элемента в DOM — экшн сработает и переместит его в указанный элемент. Демонтируется элемент штатным обработчиком Svelte, так что нет необходимости делать это в destroy функции экшена.
Я лично считаю экшены одной из самых крутых штук в Svelte — очень простая идея — жизненный цикл для любого элемента в DOM, а столько интересных возможностей даёт.
Интересно, что вы такого в React-версии для Button и Switch написали, что они в два раза больше оказались?
Танцы со стилями ) Кнопка получает много параметров, влияющих на внешний вид, на Svelte это оказалось сделать проще. Если сравнивать чисто JS, то это 39 строк в Svelte и 90 на React
А на React-версию можно где-то посмотреть? В репозитории только svelte вижу.
React версия, к сожалению, предназначена только для внутреннего использования в компании
Понятно, но это, к сожалению, убивает всю объективность графика в конце статьи. Вы можете нарисовать столбик любой длины, и никто кроме ваших коллег это перепроверить не сможет.
Объективное сравнение с примерами можете посмотреть здесь
https://habr.com/ru/post/471702/
Обратите внимание на пример с toggle, это часто используется в библиотеке
Ответил здесь
2) Можно сэкономить строку `export const App;` и подключать `import { App } from './App`
3) Если отбросить реальный бред и импорты, то разница в кол-во кода реально маленькая, и ей можно принебречь
4) Главное чтобы код был очевидным, легко читаемым и понятным, если из-за этого придется написать на пару строчек кода больше, то вообще пофигу как бы или нет?
5) React надо использовать с MobX, чтобы получать от него удовольствие. Голый реакт или реакт + redux это то ещё дно. Svelte и Vue будут разумеется лучше. Но вот react + mobx это совсем другая история
1) А зачем вы считаете css строки кода? css к реакту не имеет отношения
Svelte предоставляет крутые возможности по анимации компонентов и классное api управления классами, это здорово сокращает как JS код, так и CSS. А еще модульность CSS позволяет избавиться от BEM, SCSS и всего остального. При этом никаких дополнительных зависимостей и настроек в проекте не потребуется. Поэтому позволил себе включить CSS в подсчет
2) Можно сэкономить строкуexport const App;и подключатьimport { App } from './App
И минифицировать )
3) Если отбросить реальный бред и импорты, то разница в кол-во кода реально маленькая, и ей можно принебречь
Если хотите, можем устроить челендж, кто напишет компактнее?
4) Главное чтобы код был очевидным, легко читаемым и понятным, если из-за этого придется написать на пару строчек кода больше, то вообще пофигу как бы или нет?
Согласен, но обычно, чем меньше кода, тем легче его читать и понимать )
5) React надо использовать с MobX, чтобы получать от него удовольствие. Голый реакт или реакт + redux это то ещё дно. Svelte и Vue будут разумеется лучше. Но вот react + mobx это совсем другая история
У каждого есть свой любимый инструментарий разработки, у меня это Svelte
2) Это экономия на спичках.
3) Мой опыт не такой яркий как статистика в статье, но в 1.5 раза компоненты отличаются стабильно.
4) Да это главное, но причем тут React?
5) Верно сам по себе React довольно ущербный. Там даже нет нормального state management. Mobx очень крут и на ряду с некоторыми решениями для стилей, например, styled-components, более-менее подтягивают React до уровня Svelte или Vue. Но не нужно забывать что Mobx это + 18Кб к бандлу, styled-components еще + 12Кб и невнятный рантайм плюс сам React/ReacDOM еще порядка 40Кб. Итого +70Кб только на старте. У вас там у юзеров каналы резиновые что ли? В такой размер на Svelte можно целое приложение написать.
Насчет размера бандла — загон. В реальности, после десятка других либ, будет в лучшем случае 200Кб и 150Кб. И тут размер бандла на hello world теряется.
У реакта есть микро аналог https://preactjs.com/, мы начинали на нем один прод проект. В итоге вернули реакт, потому что смысла не было, а постоянная боль с тем, что нет экосистемы того не стоит.
Я не знаю о каких нуждах UI идёт речь… но на простом мобильном сайте интернет магазина в 30 экранов набирается больше 100кб сжатого кода (но не gzip) разметки, логики и тп. Без либ.
Если вы покажите хотя бы один продакшен SPA проект с теми же 20-30 страницами, над которым трудились больше двух человек и размером бандла меньше 200кб, то мне придётся пересмотреть всю свою работу.
Я не знаю о каких нуждах UI идёт речь…
Минимальный список того, что пришло в голову сходу и нужно для полноценной разработки UI и чего нет в стандартных 40Кб gzip React:
- Работа со стилями компонентов
- Система биндингов и кастомных событий
- Управление состоянием компонентов
- Управление глобальным состоянием
- Управление жизненным циклом DOM элементов
- Анимации и переходы
- Композиция компонентов на основе множественных вставок (slots)
Я не в курсе как можно делать современные UI без этого базового набора фичей.
- css-modules или complie-time css-in-js… это вообще никак не относится к реакту, как и сам jsx и куча других штук.
- и не нужно это пихать в реакт (кастомные события точно)
- this.setState / useState?
- мы пользуемся этим https://github.com/andregardi/use-global-hook/blob/master/index.js, на приложения в 10-30к строк этого с головой, 60 строк.
- не понял чем вы хотите управлять, смысл react в декларативности, а если кто лезет управлять руками, то это попахивает
- тут да, react не скрывает всю сложность этого, в отличии от svelte, круто если у вас процент такого кода дотягивает хотя бы до 1%
- children спец синтакс, тк чаще всего будет один "слот". Что тут не устраивает <MyComponent header={<Header />} footer={<Footer />} />?
В общем у вам пока только наброс на вентилятор и без конкретных примеров тянет только на диванного критика. На http://mustlab.ru/ нет пример работ, поэтому хотелось бы увидеть пару красивых проектов и готов отдать на аутсорс пару наших проектов =)
- Да этим и приходится пользоваться. Это пробел в скилах React — отсутствие возможности написать законченный компонент силами только React.
- Без этого мы и получает аналог callbacks-hell, только на новый лад. А так как в мире React компоненты до-кучи принято дробить мелко, получается еще и components-hell.
- По поводу this.setState сомневаюсь, учитывая что его фактичеки не советую использовать. Насчет хуков согласен — это большой шаг вперед.
- Это прекрасно, но хорошо когда есть хоть какой-то встроенный механизм. Отлично когда этот механизм еще и представляет возможность расширения. На практике же повсеместное засилие Redux.
- Одно другому не мешает. Можно декларативно управлять жизненным циклом DOM элементов. Более того, в реальном мире React-приложений часто приходится юзать рефки на элементы, а там ни о какой декларативности и речи быть не может. А вот Svelte нашел способ.
- Сдается мне вы никогда не рвали на себе волосы, чтобы реализовать сложные анимации и переходы на React. Особенно до появления специализированных решений, да и с ними думаю тоже. Svelte же не просто скрывает сложность, он делает это простым. FYI, вы пишете анимации и переходы с помощью JS функций, а в итоге они компилируются в нативные CSS-анимации, которые выполняются вне основного треда. Магия.
- Вот именно, children может быть всего один и это невнятное ограничение. Передача компонентов через пропсы это вариант, но вариант не аналогичный, так как делая так, вы делегируете управление жизненным циклом этих компонентов в принимающий компонент. Инициализация через slots или children оставляет управление ЖЦ в родительском компоненте. Кроме того, нет никакой возможности пробросить часть стейта из MyComponent в разметку внутри слота (children). То что во Vue называется scoped slots.
- Вы же понимаете, что children это просто props.children, а похожих пропсом может быть сколько угодно, только без сахара. Передать state это <MyComponent footer={state => <MyFooter {...state} />} />. Я не думаю, что во vue/svelte это работает по другому, тут можно только сказать "мне не заходит jsx", но у этого подхода огромный плюс из коробки — ts/flow работает сразу.
Ладно, спор в тупике. Единственное, что я сказал, что в реальном мире тыкать в размер react не стоит, это капля в море, а вот выискивать аналог чего-то вроде react-slick придется (со свайпами, адаптивнастью) или писать свой за бабки заказчика (и я не один раз пытался его выкинуть из react проектов, потому что жирный и не получается, потому что это 50-100ч на разработку и тестироние, $3к за слайдер не адекватно).
ИМХО Встроить svelte в react приложение нормально (мы встраиваем elm, проблемы такие же). Но писать что-то за чужие деньги чисто на нем (как и сказано в конце статьи) я точно не буду.
Вы же понимаете, что children это просто props.children, а похожих пропсом может быть сколько угодно, только без сахара. Передать state это <MyComponent footer={state => <MyFooter {...state} />} />.
Странно, но мне казалось что идею render props уже давно забраковали даже их создатели, но видимо не все в курсе. Видел более сложные кейсы с render props'ами и это уже props-hell какой-то. Не знаю зачем городить плохие решения если есть хорошие.
Я не думаю, что во vue/svelte это работает по другому, тут можно только сказать «мне не заходит jsx», но у этого подхода огромный плюс из коробки — ts/flow работает сразу.
Это самый жирный плюс JSX — TS в свое время заморочились с его поддержкой. Тут вопросов нет.
Ладно, спор в тупике. Единственное, что я сказал, что в реальном мире тыкать в размер react не стоит, это капля в море, а вот выискивать аналог чего-то вроде react-slick придется (со свайпами, адаптивнастью) или писать свой за бабки заказчика (и я не один раз пытался его выкинуть из react проектов, потому что жирный и не получается, потому что это 50-100ч на разработку и тестироние, $3к за слайдер не адекватно).
slick-carousel оборачивается в декоратор для Svelte за пару часов. Никаких тестирований не нужно. Причем размер этого чуда будет до кучи меньше чем реакт версия. Короче панч в сторону экосистемы не засчитан.
Но писать что-то за чужие деньги чисто на нем (как и сказано в конце статьи) я точно не буду.
Вы видимо думаете что только вы умеете деньги считать, а те, кто уже сделал и делает ставку на Svelte кругом дураки. ))) По факту же, Svelte как раз экономит деньги.
Ссылку можно на этот slick-carousel? А то я, невежда, знаю только slick на jquery, который поболее будет весить react версии.
Странно, но мне казалось что идею render props уже давно забраковали даже их создатели, но видимо не все в курсе.
у вас не верная информация. render props живее всех живых и как раз повсеместно применятся для реализации слотов.
источник
Не думаю, что в любом другом проекте метрики радикально изменятся в обратную сторону.
То есть по вашему что 200Кб, что 150Кб это одно и тоже?
Для тех, у кого всё ещё dial-up модем это не одно и то же, для всех остальных разницы нет, более того что 300kb что 150kb разницы нет, 1 раз загрузил, потом всё равно из кэша берет браузер
Лично мой опыт такой: у меня в продакшен есть два (почти одинаковых) приложения с функционалом который отличается одним экраном, набор сторонних библиотек идентичен, оба проекта собираются через webpack. Первое приложение было написано на Vue, когда вопрос встал о втором приложении то решено было написать на Sveltejs в рамках эксперимента.
По итогу получилось что размер бандла на Sveltejs в два раза меньше чем на Vue.
А вот не факт что меньше будет. Всё-таки DOM API довольно многословно.
В стиле:
const q = (s) => document.querySelectorAll(s);И т.д. и т.п. плюс после минификации все равно будет меньше 100% чем Svelte значительно, так что для тех кто гонится за маленьким бандлом ванила в помощь
Если так делать — получится write-only код...
Но это именно, то что делает Svelte =) Скомпилированный код получается близок к тому, что бы вы написали на vanilla(в REPL можно посмотреть на вкладке JS Output). В рантайме остаётся кроме бизнес-логики, хелперы непосредственной манипуляции с DOM, подобные тому, что вы написали.
Подумалось, что при мало мальской сложности проекта, оптимально писать на ваниле человеку может стать не удобно, начнет вводить понятные для себя абстракции, совершать больше ошибок, где-то быть не оптимальным. В итоге окажется, что скомпилированная vanilla от Svelte, окажется лучше и по размеру и по быстродействию. Разработчик пишет со всеми плюшками, паттернами и удобствами компонентного фреймворка, на выходе получает оптимальнейший код на ваниле.
Пруфы:
Vanilla: todomvc.com/examples/vanillajs
Svelte: svelte-todomvc.surge.sh
Итого:
Все что говорите вы или любой другой человек, но это не подтверждено кодом на который можно взглянуть и проверить, а правильное ли вообще это сопоставление/сравнение, то это просто пустые слова которые ничего не значат и брать их в расчет нельзя.
С такой логикой вам нужно выкинуть из дома молоток и купить побольше микроскопов что бы гвозди забивать.
В любом случае это выбор каждого. Мне платят не за конкретный стек, а за реализацию бизнес задач. И если я это делаю хорошо, то пользователи довольны, если пользователи довольны, то и бизнес доволен, а если бизнес доволен, то и мне хорошо.
В 2020 году, когда мобильные, embedded устройства и всякого рода IoT, для которых жирный и тормозной React не лучший выбор, уже во всю занимают лидерские позиции, вы мыслите шаблонами десктопа и при говорите о востребованности. Ну не смешно ли.
Но не нужно забывать что Mobx это + 18Кб к бандлу
MobX tree-shakable, вообще-то. Все 18Кб вы едва ли вытащите.
Точно нет. В Sapper есть прекрасный файл роутер, которым я пользуюсь. Плюс уже есть большой выбор роутеров для svelte.
Чему я научился, написав библиотеку компонентов на Svelte