Comments 17
Хорошо, но было б замечательно если бы было что-то более детальнее чем на https://learn.javascript.ru/ ,
learn.javascript отличный сайт, там много хорошего материала.
Я бы хотел написать еще пару статей на эту тему, подскажите что можно было бы улучшить? и что вы имеете ввиду под более детальнее? Больше примеров?
Что-нибудь специфическое в использовании, редкое использование. Хитрости в применении.
загрузка html (нет хука, который бы срабатывал, когда темплейт загружен) серверный рендеринг с деклоративным шадов домом,
Вообще сделать компонент с navigation api, это в любом случае понадобится если компоненты использовать
Может вот эта статья подойдет https://habr.com/ru/articles/962778/
мне в своё время очень помог freeCodeCamp, мне кажется, что отличное дополнение к базовому learn.javascript
Вэб компоненты слишком громоздки/многословны:
Покажите мне код
Например вот как может выглядеть компонент кастомного счетчика на Фьюзоре:
const ClickCounter = ({count = 0}) => (
<button click_e_update={() => count++}>Clicked {() => count} times</button>
);
Это разные вещи, и там Вам ответили
Лучше один раз изучить стандарт (W3C), чем для каждого фреймворка запоминать отличия.
Вэб компоненты слишком громоздки/многословны
Потому что веб-компоненты — всего лишь набор стандартов/DOM API/примитивов. Фьюзор, как я понял, это библиотека/фреймворк с дополнительной логикой и, судя по JSX, с компилятором. Поэтому фьюзор (или что-либо ещё) нужно сравнивать не с голыми веб-компонентами, которые работают в браузере как есть без сборщиков, компиляторов и кастомного синтаксиса, а с соответствующими библиотеками/фреймворками, в основе которых веб-компоненты: Lit, Stencil, Symbiote и так далее. Они как раз решают проблему многословности стандартного API.
Вы правильно поняли, Фьюзор это библиотека с одним уровнем абстракции над document.createElement, который помогает декларативно создавать элементы и потом их обновлять с помощью функции update. Компоненты в нем являются простыми функциями возвращающими созданные таким образом элементы. Что в отличии от вэб компонентов гораздо удобнее - функции гибче классов. Компилятор нужен при только использовании JSX, но не нужен при функциональном стиле:
import {button} from '@fusorjs/dom/html';
const ClickCounter = (count = 0) =>
button({click_e_update: () => count++}, 'Clicked ', () => count, ' times');
Про декларатиынй shadow dom ещё бы написали. Очень важная и определяющая возможность, для самой больной темы серверного рендеринга. С декларативным shadow dom это стало значительно проще.
Очередной некропост о технологии пятнадцатилетней давности. Я это использовал еще до появления всех этих ваших новомодных vue, svelte и т.д.
Я это использовал еще до появления всех этих ваших новомодных vue, svelte и т.д.
Очередной некропост о технологии пятнадцатилетней давности
Раньше 2017 года не могли. Тогда уже vue и react были.
Я как только он появился начал на них писать и это один из агрументов был, что никто не сможет написать, что я это 15 лет уже использую. ))) Раньше меня вы могли начать писать, только если вы являетесь разработчиком этих стандартов.
Сочетание этих технологий стало стандартом к 2018 году.
Да и тогда это фреймворк полимер был, поддержка очень плохая была.
Стандарту 8 лет максимум
Я наверное немного отстал от жизни) Просто во фронтенде такое многообразие библиотек и фреймворков что все изучить просто нереально (Я до этого писал на React и Vue). Сейчас решил посмотреть на то что есть из коробки и мне это очень понравилось, вот и решил поделится)
В этой статье, как и во многих вводных статьях про веб-компоненты, есть важное допущение. Веб-компоненты сравниваются и напрямую противопоставляются популярным JS-фреймворкам. Если смотреть с такой стороны, то веб-компоненты во многом будут уступать фреймворкам по функциональности и удобству разработки.
Например, нет декларативного синтаксиса шаблонов для привязки данных, циклов и условной отрисовки. Нет реактивных данных. Не хватает многих привычных вещей из фреймворков. С помощью современного JS и Web API всё недостающее можно реализовать, но для многих это будет созданием велосипеда и тратой времени.
Поэтому мне кажется, что правильнее смотреть на веб-компоненты, как на набор низкоуровневых примитивов браузера, расширений DOM API, которые позволяют создавать собственные DOM-элементы с логикой и стилями. Как эти примитивы использовать и что из них можно построить — уже другой вопрос. А создать можно много чего.
Ну и проводить какие-то аналогии и сравнения с тем же React или Vue не голых веб-компонентов, а таких же надстроек над DOM и веб-компонентами, как, например, Lit.
Вообще говоря у меня не было изначально цели сравнивать библиотеки, я считаю веб компоненты могут служить неплохим дополнением для библиотек. Например можно сделать какие-то базовые компоненты а потом использовать их в связке с React, Vue на разных проектах.
Веб компоненты не так удобны в разработке, тут согласен. Но тем не менее ряд преимуществ все таки имеются:
1. не нужно устанавливать доп пакеты/модули (можно даже обойтись без сборки);
2. нет проблем с версионированием;
3. на веб компонентах вы пишите сразу агностик, а значит компонент который вы реализуете один раз могут использоваться и с тем же React, Svelte, Vue и тд.
4. дебажить существенно проще: благодаря небольшому стэк трейсу (в отличии от vue например) и отсутствие computed свойств. Когда в коде появлюятся длинные цепочки computed свойств - это настоящая проблема тк в какой-то момент ты перестаешь понимать что происходит (лично мое мнение, я с этим сталкивался достаточно часто:) )
Гайд по Веб Компонентам (Web Components)