эти параметры уже существуют в базовых элементах и лучше как раз через сеттеры геттеры их смапить прямо или менять через евенты, а не хранить. Так или иначе веб-компоненты вас в этом никак не ограничивают, как вам кажется необходимым так и можно сделать, единственно, что какие-то арихитектуры навроде реактовской я бы бездумно воспроизводить не стал, т.к. они придумывались как ответ на кашу-вермишель фронтенд технологий 10и летней давности, а с вебкомпонентами все поменялось и браузер может сам решать задачи сборки мусора или оптимизации
а вы уверенны, что это внутреннее состояние компонентам необходимо? мне кажется это всеравно что пытаться кастомные элементы постоянно себя целиком перерендеривать с диффом как в рякте
чем по непонятным причинам стремиться к абсолютной синтаксической чистоте HTML, CSS и JS в пределах вью.
причины происходят из практики, например вам надо проехаться автопрефиксором или другим пре-пост процессорам по всем стилевым файлам или только по файлам определенного модуля, решение для файлов объединяющих все будет настолько сложным, что в условиях экономии на часах в современной разработки его реализовать никто никогда не даст
Я хотел понять какая есть альтернатива, вы объяснили, мне не понравилось — ну, бывает.
важно понимать, что альтернатива может существовать, ее конкретных реализаций в современных фреймворках я и правда не видел, но дело тут в том, что 90% современного фронтенда слепо увлечены анти-паттерновыми решениями (в популярных сейчас фреймворках) и бестолковыми идеями навроде таких, что веб-разработка больше не нужна и все заменит искусственный интеллект и конструкторы сайтов с готовыми виджетами или что у них есть какая-то такая важная оптимизационная идея-причина, которая отменяет инженерные практики
то при установке этих двух элементов к себе в приложения я неизбежно получу исключение.
вы получите исключение при попытке использовать другой класс для того же тегнейма, при этом вы всегда можете добавить проверку на то определен ли уже такой тегнейм, т.е. это как раз не проблема использование глобального скоупа, а решение проблемы в виде ограничения, без которого могли бы возникать коллизии использования тега разными компонентами
да этот пример просто расширить скорее всего не выйдет, а вот на хорошо структурированный код angular-material/cdk я легко менял под свои задачи наследуя, расширяя и переопределяя классы компонентов, шаблоны, не переписывая весь грид с нуля, не копипастя и даже не особенно вникая во внутреннее устройство. В этом главная задача технологий — быть расширяемыми и доступными для участия в доработке и развитии другими людьми желательно не сильно завися от моды.
>> [известная картинка с разными точками зрения на то, что такое компонент]
т.е. вы считаете что .js файлы это подходящее место для верстки? а прямое связывание — хороший способ разрабатывать системы с расширяемой семантикой? мне кажется придерживаясь таких принципов лучше будет рендерить картинку в пикселях и изменять ее по принципам работы видео-кодеков, зачем эта несуразность с генерацией хтмл?
говнокодом чаще используют именно описанный вами подход
это были лихие нулевые, браузерное апи и сам джаваскрипт были убогими, нахлобучки типа жквери страшными и такими же сиюминутно мотивированными «мне просто календарик заанимировать», т.е. вот это вот самое принесение в жертву принципов разработки субъективному удобству решения оперативной задачи и породило тот самый ужас, который вы не хотите видеть модных ныне подходах
когда есть геттеры/сеттеры и прокси, зачем вам дифф алгоритм? изменять данные и связи всегда дороже чем создавать новую копию на основе старых и этого изменения, а у компонентов и не должно быть состояния, которое нельзя потерять вместе с компонентом
илнайна верстки в джаваскрипте ничто не может оправдать, извините, т.к это нарушение принципа разделения ответственностей и всего прочего mvc. Понятно, что лично вам может быть говнокодить удобненько. Но я много и много раз видел вермешели смешивающего кода в который невозможно (противно) было развивать и поддерживать. Прикладные задачи всегда превращают такой код в помойки говнокодов.
Ну… это хотя бы позволяет использовать возможности IDE
вот в примере с реактом-редаксом, который я привожу в данном среде, у меня интелиджа не могла зайти в определение прокинутого через пропсы метода, а когда я внутри своего класса-вебкомпонента дергал методы заинжекченного метода сервиса — могла, т.к. его контракт определялся типом свойства класса.
При следовании архитектуре веб-компонентов, все внутренние обработчики будут внутри класса-компонента, все внешние вы и так не узнаете если они «прокинуты через пропсы», хотя, на самом деле, в случае нативного кода все прямые бинды достаточно просто вычисляются из Web Developer Tools а непрямые через свойство path у эвента который вы поймаете дебагером, а вот если у вас модульное приложение на фреймворке со свой шиной и биндингом это не понятно как сделать, а если вы имели ввиду монолит это немного не тот класс решаемых задач.
я думаю дело не только во мне, а еще и в том, что в браузерном одном потоке нет настоящей асинхронности, и он не мог сделать выход из цикла, что-бы запустить редаксо-реактовую магию биндинга, а в случае в нативным кодом все-таки оптимизировал сам цикл. Честно говоря, я бы хотел как-то сравнить реакт и вебкомпоненты (натив), но не понимаю как сделать это справедливо учитывая, что у вебкомпонентов нет ориентированности на перерендеринг компонента и задачи биндинга и рендеринга можно решить без архитектурно-алгоритмических ухищрений
я трогаю не элемент а прокси объект, вообще я сделал такой же точно по входным тербованиям пример на реакте (вызывал инкремент у редакса) и он выжирал всю память и заваливал вкладку не обновив значение ни разу, потом я его упростил убрав функцию бенчмарка, но ничего не поменялось, для меня этот код выглядел вполне естественным. У меня сложилось гипотеза, что в случае с нативом браузер оптимизировал цикл высчитав финальное значение и отрисовав сразу, но продолжая колбасисть код бенчмарковых фукнций 1000и раз и в случае с реактом он этого сделать не смог, а может быть пытался построить какую-то оптимальную цепочку рекурсивного вызова своего инкрементального рендера
Насколько я помню, это не работает для Custom Events.
вообще, я был сторонником addEventListener и прочего биндинга-хендлинга сугубо в коде, на мой взгляд правильнее добавить проверки и бросить иключение или даже ворнинг если элемент не был найден селектором. Что до повторного упоминания айдишника, то при биндинге в шаблоне вы точно так же дважды минимум упоминаете имя метода-обработчика, так что тут как ни крути:) но наверное можно использовать особенность мапинга элементов по айди на глобальный (или может уже и стековый для компонента в теневом поддереве) скоуп
Тут связь обсуждаемого и CSS-фреймворков я не уловил.
что-бы произвести биндинг или рендеринг на шаблон вам не надо дополнительно размечать его специальными аттрибутами, можно использовать селекторы для адресации элементов, как раз как-то так было в бекбоне, но там по умолчанию имя метода-обработчика тоже задавалось строкой. Вы конечно возразите, что мол компайл-тайм нахождение ошибок будет надежнее, однако, компиляция это на самом деле транспиляция, и в какомнить рякте вам всеравно все преимущества прямого связывания нивелируют развязанными пропсами или другой, но той же по сути шиной событий
Я и написал, что я как разработчик не хочу использовать низкоуровневые апи в задачах, связанных с разработкой продуктов. Что касается Lit-Element, полагаю что они использовали lit-html потому что это их же разработка, внутри которой DOM API используется напрямую. Зачем им еще раз писать тоже самое в lit-element не очень понятно.
сейчас браузерное апи не такое уж низкоуровневое, скорее архитектуры популярных фреймворков напоминают подход идущий от оптимизации с сомнительным результатом с какими-то фантастическими придумками объясняющимися только оптимизационными потребностями
да, течет и жрет ресурсы единственно возможного в одном потоке ядра хоть и не так быстро как было у меня с реактом и редаксом, это миллион апдейтов:)?
вот код который делает миллион апдейтов на нативе, но его браузерый рантайм оптимизирует и он выполняется за 5-6 секунд сразу показывая финальный результат%)
let data = { foo: 'bar'};
let template = document.importNode(document.getElementById('comp-template').content, true);
let container = document.getElementById('container');
container.appendChild(template);
let dataEl = container.querySelector('#data');
let dataProxy = new Proxy(data, {
set(target, prop, value) {
target[prop] = value;
dataEl.innerHTML = value;
return true;
}
});
(function() {
console.log('starting ..');
var i = 0;
console.log(bench(() => {
dataProxy.foo = ++i;
}, 1000000, [], this)); // 1 million updates == 8.3 secs
})();
вы можете использовать и onclick=«elementId.someMethod()», однако кроме биндинга эвентов шаблонизаторы и фреймворков привносят еще много своих констркуций (аттрибуты биндинга, анимации, конфигурации данные и т.п.), которыми разработчики активно пользуются (а как же не пользоваться если так проще) создавая систему из 2х шаблонизаторов, потому что сразу на коде фреймворка сделать макет выйдет равноценно полной реализации. Я не вижу большой порочности в походе бекбона, хотя ее можно было бы улучшить прямым биндингом, есть люди которые вообще фантизируют разработку искусственным интеллектом, а не только без работы над дизайном-макетом. Понятно, что можно просто использовать компоненты цсс фреймворка для многих случаев, но вы просто понижаете градус задач говоря «ах, раз этого нет значит оно и не нужно».
если фреймворки оборачивают стандартное апи и делают это не очень казуальным образом, то наверное в этом нет проблемы, но большинство популярных фронтенд фреймворков не только не следует стандартам но разрабатывается поперек паттернов (принципов) разработки ПО, создавая этакий мирок или секту живущую по правилам задом-наперед
и поменяйте так что-бы он делал миллион инкрементов (изменений) при нажатии кнопки, никакой особой магии просто иммитация значительной работы в режиме SPA, и вам не нужны будут никакие бенчмарки
обычно все эти аттрибуты добавляются к исходной верстке в исходно обычный хтмл (если фреймворк требует полного переписывания это отдельная боль, чаще от работы с дизайном в таких системах просто отказываются), т.е. у вас в процессе получается 2 шаблона, макетный и фреймворковый. Каждый такой атрибут это потенциальный баг, т.к. велика вероятность, что разработчик-интегратор его пропустит, опечатается или что-то такое еще сделает случайно-произвольное. Кроме второго шаблона, вам все равно надо еще докодировать еще настоящей бизнес-логики, или доинтегрировать если это не первая итерация и тут количество потенциальных ошибок будет возрастать геометрически помноженное на проблемы коммуникации если этим занимаются разные узкие специалисты. В тоже время в промежуточном шаблоне нет необходимости, т.к. хтмл вместе с цсс селекторами сам по себе является прекрасным шаблонизатором, т.е. вам достаточно иметь некоторый обычный хтмл + цсс и js код производящий всю связывающую магию ориентируясь на свою конфигурацию и адресуя элементы по селекторам с появлением shadow dom даже снова можно вспомнить про более эффективные с точки зрения производительности айдишники, поиск внутри под-дерева не будет тормозить в любом случае, а прямой биндинг данных даст безусловный выйгрыш относительно разных хитрых придумок с дифом перерисовок или масштабированием операций изменения.
не лучше, т.к. кучу кода вы можете унифицировать в методе или классе, а явно захаркоживаемые в шаблон аттрибуты создают дополнительную сложность и интеграции и развитии при изменении дизайна-верстки вы переверстываете весь шаблон допуская много ошибок с этими аттрибутами и тратя кучу времени, переписываете код, а когда в шаблоне нет особенных синтаксических конструкций вы только переписываете код, может быть даже в минимальном объеме%)
причины происходят из практики, например вам надо проехаться автопрефиксором или другим пре-пост процессорам по всем стилевым файлам или только по файлам определенного модуля, решение для файлов объединяющих все будет настолько сложным, что в условиях экономии на часах в современной разработки его реализовать никто никогда не даст
важно понимать, что альтернатива может существовать, ее конкретных реализаций в современных фреймворках я и правда не видел, но дело тут в том, что 90% современного фронтенда слепо увлечены анти-паттерновыми решениями (в популярных сейчас фреймворках) и бестолковыми идеями навроде таких, что веб-разработка больше не нужна и все заменит искусственный интеллект и конструкторы сайтов с готовыми виджетами или что у них есть какая-то такая важная оптимизационная идея-причина, которая отменяет инженерные практики
вы получите исключение при попытке использовать другой класс для того же тегнейма, при этом вы всегда можете добавить проверку на то определен ли уже такой тегнейм, т.е. это как раз не проблема использование глобального скоупа, а решение проблемы в виде ограничения, без которого могли бы возникать коллизии использования тега разными компонентами
т.е. вы считаете что .js файлы это подходящее место для верстки? а прямое связывание — хороший способ разрабатывать системы с расширяемой семантикой? мне кажется придерживаясь таких принципов лучше будет рендерить картинку в пикселях и изменять ее по принципам работы видео-кодеков, зачем эта несуразность с генерацией хтмл?
это были лихие нулевые, браузерное апи и сам джаваскрипт были убогими, нахлобучки типа жквери страшными и такими же сиюминутно мотивированными «мне просто календарик заанимировать», т.е. вот это вот самое принесение в жертву принципов разработки субъективному удобству решения оперативной задачи и породило тот самый ужас, который вы не хотите видеть модных ныне подходах
вот в примере с реактом-редаксом, который я привожу в данном среде, у меня интелиджа не могла зайти в определение прокинутого через пропсы метода, а когда я внутри своего класса-вебкомпонента дергал методы заинжекченного метода сервиса — могла, т.к. его контракт определялся типом свойства класса.
При следовании архитектуре веб-компонентов, все внутренние обработчики будут внутри класса-компонента, все внешние вы и так не узнаете если они «прокинуты через пропсы», хотя, на самом деле, в случае нативного кода все прямые бинды достаточно просто вычисляются из Web Developer Tools а непрямые через свойство path у эвента который вы поймаете дебагером, а вот если у вас модульное приложение на фреймворке со свой шиной и биндингом это не понятно как сделать, а если вы имели ввиду монолит это немного не тот класс решаемых задач.
вообще, я был сторонником addEventListener и прочего биндинга-хендлинга сугубо в коде, на мой взгляд правильнее добавить проверки и бросить иключение или даже ворнинг если элемент не был найден селектором. Что до повторного упоминания айдишника, то при биндинге в шаблоне вы точно так же дважды минимум упоминаете имя метода-обработчика, так что тут как ни крути:) но наверное можно использовать особенность мапинга элементов по айди на глобальный (или может уже и стековый для компонента в теневом поддереве) скоуп
что-бы произвести биндинг или рендеринг на шаблон вам не надо дополнительно размечать его специальными аттрибутами, можно использовать селекторы для адресации элементов, как раз как-то так было в бекбоне, но там по умолчанию имя метода-обработчика тоже задавалось строкой. Вы конечно возразите, что мол компайл-тайм нахождение ошибок будет надежнее, однако, компиляция это на самом деле транспиляция, и в какомнить рякте вам всеравно все преимущества прямого связывания нивелируют развязанными пропсами или другой, но той же по сути шиной событий
сейчас браузерное апи не такое уж низкоуровневое, скорее архитектуры популярных фреймворков напоминают подход идущий от оптимизации с сомнительным результатом с какими-то фантастическими придумками объясняющимися только оптимизационными потребностями
вот код который делает миллион апдейтов на нативе, но его браузерый рантайм оптимизирует и он выполняется за 5-6 секунд сразу показывая финальный результат%)
github.com/zakangelle/generator-redux-stack
и поменяйте так что-бы он делал миллион инкрементов (изменений) при нажатии кнопки, никакой особой магии просто иммитация значительной работы в режиме SPA, и вам не нужны будут никакие бенчмарки