на тот момент не было даже нативной версии библиотеки а писать заново слишком много времени заняло бы, по этому мне было проще свою сделать чем портировать с реакта на Vue( или на натив что еще сложнее

Да, прекрасно вас понимаю, изначально первая версия появилась от 1 проекта где создавал кастомную CMS для заказчика и там захотели очень много редакторов + сортировочных листов, решили использовать тоже vue-draggable но не понравился результат дизайнеру и заказчику, дизайнер с заказчиком чето там напридумывали и по итогу захотели увидеть в редакторе писем preview когда на зону наводят элемент картинки...

Короче очень суровая таска была из за того что таких решений не было, увидел dnd-kit для реакта и понял что это решение помогло бы если оно было для Vue, на тот момент не было, и я вдохновился этой библиотекой и написал свою, и после через пол годика написания своей человек переписал библиотеку на натив и сделал для Vue dnd-kit тоже)))

Мне вот тоже теперь обидно немного)
Спасибо за комментарий <3

Конкретно сам CLI написан на TS, а сами компоненты на нативном JS для того чтобы можно было использовать данное решение без сборки. Специально указан ХАБ битрикса потому что по сути появился проект где была у меня такая необходимость в вебкомпонентах, и выполнять сборку через bitrix/cli или vite вообще не хотелось, в будущем планирую добавить d.ts

По поводу Tree компонента уже есть идеи, я планировал сделать что то вроде модуля с dnd чтобы можно было реализовывать DnD через HTML теги просто с минимальным JS, но это слишком набудущее, DnD потом будет.

Просто в планах взять сначала переписать свою первую либу про которую вы упомянули на нативный JS/TS + добавить selection area (ну типо окно как на винде когда юзер зажимает и область появляется и все элементы которые туда попали можно драгать)

Как то так

Привет, не проверял, хороший вопрос надо будет проверить, но скорее всего все должно работать так как все работает примитивно

Не знаю как бы сказать но я посмотрел на свойства и как они поддерживаются

Просто не думал что кто то еще сидит на старых браузерах, опять же 115 firefox не такой уж и старый если сравниваем IE, но все таки, я думаю можно вполне использовать, да и переписать стили с light-dark на :root.dark, :root.light вообще не так уж и сложно учитывая что все переменные в одном файле

В любом случае все правы по своему, проблема остается, веб компоненты это все таки справедливости ради не Vue.js( это довольно нишевая тема, но на каких нибудь проектах Django / Bitrix, в целом очень даже солидно могут помочь)

скорее всего проблема в том что используется свежая реализация светлой темы и темной темы для CSS, light-dark, возможно она не поддерживается, спасибо за комментарий я посмотрю в чем проблема

Аааа я понял, да тут будет косяк, как раз есть компонент каледнаря в либе и он управляется со стороны, чтобы разработчик сам кнопки делал которые ему нужны, и вот тут возникает действительно проблема потому что ничего отрендерено не будет(

Вообще сейчас Shadow DOM поддерживается всеми браузерами кроме IE, и Shady DOM не используется в библиотеке

(Вообще это не точная информация, может быть Lit под капотом использует)

Тут момент я бы сказал будет как в Nuxt когда сервер рендерит блок а потом происходит hydration на клиенте и компонент оживает. Так как в моих компонентах все стили привязываются к тегу, браузер даже до JS может покрасить этот тег, лишь после того как DOM полностью загрузился там уже мы браузеру даем понять что это кастомный элемент. И Если мы что то внутри него рендерим то сервер это не увидит (именно рендерим HTML в нашем компоненте, а не в слоте) Все что рендерим в слоте сервак увидит и все будет хорошо

Надеюсь ответил на ваш вопрос)

Ну в целом по фактам, но есть пару НО

Уж больно категоричны вы что вебкомпоненты "мертворожденны"
Современные браузеры очень хорошо оптимизированы для работы с DOM. Проблемы с производительностью возникают при чрезмерно частых операциях, да это не виртуальный DOM а ShadowDOM, но допустим тот же самый input range, там под капотом вебкомпонент по сути основанный на дивах. Так что в каком то плане это стандартная браузерная технология и даже во Vue/React и прочих фреймах всегда будет доля вебкомпонентов, к примеру есть проекты где юзается Swiper в виде вебкомпонента (не самое хорошее решение но оно вполне себе рабочее)

По поводу конфликта имен, ну да легко можно словить если только это как то не стандартизировано, в данном случае проблем быть не должно если сам разраб не захочет себе устроить себе головняк.

По поводу отвал стилей в теневом доме это да, есть такая проблема, только мое решение не использует теневой DOM, там тупо CSS файлик который биндится на тег и проблем тут быть не может. + Используется ::part в стилях для получения доступа к теневым элементам.

А так в целом я с вами согласен) я же описал это в статье что это нишевая тема и в маленьком количестве проектов это пригодится.

Изначально когда делал это все я понимал что это больше не для фронтов решение, а больше для бекендеров которым лень писать фронт копаться в стилях, использовать JS и все такое, да и хранить в голове названия классов своих для кнопок тоже не кайф, а тут все удобно, VSCode подсказывает аттрибуты + есть генератор этой же VSCode даты прямо в CLI.

Вообщем как то так, короче это решение было больше для проектов на Bitrix / Django или что то вроде, ну и решить проблемы с несколькими фреймами в проекте

Да я понимаю, просто очень уж захотелось релизнутся вдруг кому то уже подойдет табы аккордион, но вот как выше упомянули, табам надо навигацию сделать

CLI все сделает за тебя, он перезапишет весь компонент, я предусмотрел этот момент, а так в целом структура использует 1 файл register

Спасибо, обязательно посмотрю на выходных

Ну стили всегда можно переписать либо сделать тупо такие же стили, в этом ничего сложного) если надо могу сделать

Спасибо, исправлю)

Спасибо за референс, позаимствую что нибудь)

Я подумал что разработчик который пользуется библиотекой может не знать все подводные камни вебкомпонентов и то как работает реактивность и вместо того чтобы вычитывать всю информацию покусочкам, он просто зайдет в документацию Lit, + меньше кода

Автокомплит в процессе, я сначала всю UI либу написал на нативе а потом решил перенести на Lit, чтобы было удобно в поддержке.

Я планирую в целом сделать все для формы чтобы оно корректно работало Select, Autocomplete и прочее, чтобы оно кастомизировалось, так же Modal/ Dialog и прочее.

Спасибо за конструктивный комментарий) Тут все по фактам :3

Уже жду) В любой критике есть доля смысла, а так спасибо за напутствие