когда вы начинаете делать на фреймворке вам сразу надо проинициализировать архитектуру из нескольких библиотек и как-то переложить ваш дизайн и вашу бизнес-логику на эту архитектуру даже если вы ничего такого не хотели на самом деле, а надо было только сабмитить форму, у вас как раз будет целый SPA или куча привязывающего js кода и ui framewework/модуль типа material или antd, модуль специальных форм и валидаций для фреймворка и какая-нибудь шина. Каждый фреймворк построен по какой-то своей идеологии и мало совместим с любым другим фреймворком и нативной средой браузера.
«Использование особой формы» позволит вам сделать, все что требуется более изящно и управляемо и это как раз сильная сторона веб-компонентов, что вы любой кусок страницы можете завернуть в кастомный тег и закрепить за ним класс с жизненным циклом. Т.е. можно было самбит формы сделать добавив onclick и onkeypress обработчики прямо в глобальном скоупе тега скрипт, но это будет выглядеть как костыли, а завернутое в кастом элемент уже не будет.
в общем и целом вебкомпоненты делают тоже что и популярные фреймворки, только менее вычурным способом и на основе стандартизированных и работающих в браузерах без библиотек технологий. Т.е. они дают возможность разработчикам строить свои приложения используя стандартный апи и структурируя код так что-бы его можно было развивать и поддерживать, а результатом пользоваться без боли от скудности возможностей стандартных компонентов
в частном у элементов использующих Validation API есть например такая особенность, что если вы задали валидатор то он сразу срабатывает, т.е. делает пустое поле невалидным если оно должно быть заполненным, т.е. сходу подсвечивает ошибкой если они у вас подсвечиваются. Вот эту проблему используя свою форму можно обойти без танцев и костылей с цсс и жс например.
фреймворки городят целые рантаймы рендеринга на жс, которые жрут бесконечное количество ресурсов (батареек) даже на холостом ходу и не позволяют браузеру или разработчику оптимизировать работу без деградации архитектуры. Например, в ангуляр отключают механизм обновления и делают все руками. В рякте меняют шину раз в год придумывая все новые ухищрения.
>> Одним из побочных эффектов внедрения CSP является невозможность использовать тэги, только внешние файлы через (конечно, можно разрешить style-тэги обратно, через директиву 'unsafe-inline', но как видно из её названия, это будет ослабление вашей защиты).
html это динамическая среда, а вы опять лезете туда городить компиляторы, инлайнинг стилей создает проблемы для их переопределения, поэтому как и другие ресурсы типа картинок, стили лучше подключать из css файлов прямо в теневое дерево элемента.
В этой ситуации два веб-компонента должны взаимодействовать друг с другом. Обычно это делается в connectedCallback. Веб-компонент подключается в DOM и осматривается вокруг. В случае подобных композитных компонентов может иметь значение, на каком компоненте этот метод вызовется первым. Проведем тест:
просто надо учитывать, что html это динамическая среда, компоненты могут не только произвольно появляться, но и также исчезать из контекста браузера, поэтому они должны быть друг от друга максимально независимы, даже если образуют иерархию и взаимодействовать несвязывающими способами
Оказывается, порядок регистрации элементов влияет на порядок вызова connectedCallback. В практическом смысле это означает то, что мы не можем знать порядок вызова методов, и наш код должен быть готов обработать оба варианта. С вариантом «нас вызвали слишком рано» все просто, добавляем window.setTimeout делаем нашу инициализацию попозже. В случае «нас вызвали слишком поздно» ситуация хуже, мы уже не сможем отменить начатые операции. Поэтому на веб-компонентах не получится сделать нормально работающий компонент спойлера
компоненты могут выбрасывать эвенты вида «я загрузил данные», другие компоненты могут на них подписываться и начинать работать только вовремя без таймаутов. Технологии вебкомпонентов как раз хороши в том, что оно впервые за 20 лет развития фронтенда позволяет добиться такой работы без setTimeout.
я бы сказал что у вас приведены типичные ошибки разработчиков, а не технологии:
Вводим текст, нажимаем Enter, данные отправляются на сервер, никакого JavaScript. При желании можно избежать перезагрузки страницы, и сделать отправку данных через AJAX, но и в этом случае количество JS будет минимальным.
если вы используете свою кнопку зарегистрированную customElements, значит без JS уже не обошлось. api браузерных элементов закрыт для изменений, но открыт для расширения. Формы можно программно сабмитить с помощью FormData. Если у вас своя кнопка, то компонент формы тоже может быть целесообразно создать свой.
ну это уже магия костылей в духе питона, проблема тут в том, что вам может захотеться одних правил и подходов, а другому программисту других и система разрабатываемая в команде или одним эволюционирующим программистом по ходу развития станет выглядеть как зоопарк решений или помойка.
оно такое может показаться проще, но на самом деле это запутывает код, там где у вас бизнес-логика в одном блоке, она будет разманазна на какие-то ассемблерные магии, разобраться в которых и с дебагером будет сложно не говоря о таких вещах, чтобы взять и сделать переход к определению того, что происходит при нажатии условной кнопки.
Rx и подобные вещи хороши пока вы код одного применения умещается на экране. Вот например вам надо сделать реализацию дранэндропа или обрабатывать ввод поля ввода. Для этого надо взаимодействовать сразу с последовательностью событий, т.е. взять 3 и если там что-то подошло под критерий (есть все из: драгстарт, драгмув, драгенд) обработать, тут rx будет удобнее и изящнее, потому что выражение примерно так и будет записано как: стрим.взять(3).офильтровать(условие).выполнить(код).запуск().
Mobx тут вероятно может быть использован как rx и тогда не ясно зачем он нужен вообще. Стримы скорее всего со временем добавят в язык и rx тоже станет лишним.
Альтернативно, он может быть использован аналогично императивному подходу с хранением промежуточных состояний, что практически всегда хуже и фактически сложнее, т.к. потребует явной проработки множества кейсов.
фп дает шанс на алгоритмическом и локальном уровне, ооп — на архитектурном. Избыточное увлечение ими по отдельности действительно приводит к ухудшению качества кода, а вот разумное сочетание наоборот улучшает. Например, у меня код одного проектика был структурирован по ООПшному и эМВиСишному с помощью фреймворка Ангуляр, а некоторые события требующие сложной логики обрабатывались потоками Rx и все вместе выглядело достаточно пристойно, понятно и доступно для доработок. Если бы я пренебрегал стримами, локальный код был бы скорее всего более тяжелым для понимания, если отрицал бы ооп — готовность системы к конфигурации и доработкам, скорее всего, бы пострадала.
ООП дает шанс сделать хорошо и примеров, когда у разработчиков получилось использовать это преимущество великое множество, когда же у вас отобрали ООП, исключения, аккуратную непротиворечивую нотацию этого шанса не будет даже в перспективе развития, а будет как раз больше различного «динамического диспатча». Пример из веба:
в CMS WordPress написанном на процедурном пхп4, что-бы поменять лейаут страниц (2 колонки на 3) надо хачить код на помеси хтмл и пхп прямо в темах
а в CMS LifeRay это делается в настройках лейаута страницы (или можно программно).
и у каждого свои ещё, отсутствие исключении и дженериков всегда будет удерживать код на го на уровне перла или пхп из 90х, от которых все стремительное сбегали потом
ну прежде всего отсутствие классического ООП с наследованием, примеси в этом ключе точно также превращают код в помойку артефактов понять взаимосвязи которых очень сложно без поллитры и дебагера
С++ изобрели потому, что проекты на си т е без ООП почти всегда вырастали в помойки которые невозможно развивать и даже поддерживать сложно, у молодежи этого понимания нет им проще писать функции чем думать о полиморфизме и солиде, поэтому клоны си без классов и наследования, порождающие такие же безнадёжные помойки, но не сразу и в условиях дикой ротации кадров не важно, заходят ну и конечно просто в их раскрутку вваливаются огромные ресурсы, а диланг например всегда был сам по себе
как это не странно, но кажется им надо было астановится в добавлении новых штук, стабилизировать апи и накопить библиотек и фреймворков под типичные задачи. Но просто собирать утилитарный код на dlang не всегда удавалось даже скорее всегда не удавалось. Го и раст лоббируются комерсами, чтобы подставлять питонистов с пхпшниками, дальше инфраструктур компаний эмиграционных конвейеров где нужны регулярные скандалы с увольнениями они в силу заложенных дефектов не уедут.
без классов оно не так уж better, c++ всегда был в первую очередь "си с классами", зачем делают новые языки, такие как раст и го под ржавчину времен настоящих мужчин не очень понятно, точнее конечно есть гипотеза, что это чтобы они не конкурировали джаву с сишарпом, а формировали фрик гетто принципиально бестолковое, которое само будет разбиваться при попытке создать что-нибудь по настоящему стоящее в любой нише. Но очередной "убийца си" без классов устойчиво расстраивает простого, но опытного быдлокодера.
в чем вы видите оверхед явы? если вас смущает потребление памяти контейнерами, сейчас можно собрать стенделоун на quarkus в бинарник мегебайт 20и для рест-сервиса или 50-100 для рест сервиса с субд. И для разработчика это будет выглядеть почти так же чистенько и безлисапедно как спринг бут.
«Использование особой формы» позволит вам сделать, все что требуется более изящно и управляемо и это как раз сильная сторона веб-компонентов, что вы любой кусок страницы можете завернуть в кастомный тег и закрепить за ним класс с жизненным циклом. Т.е. можно было самбит формы сделать добавив onclick и onkeypress обработчики прямо в глобальном скоупе тега скрипт, но это будет выглядеть как костыли, а завернутое в кастом элемент уже не будет.
в частном у элементов использующих Validation API есть например такая особенность, что если вы задали валидатор то он сразу срабатывает, т.е. делает пустое поле невалидным если оно должно быть заполненным, т.е. сходу подсвечивает ошибкой если они у вас подсвечиваются. Вот эту проблему используя свою форму можно обойти без танцев и костылей с цсс и жс например.
html это динамическая среда, а вы опять лезете туда городить компиляторы, инлайнинг стилей создает проблемы для их переопределения, поэтому как и другие ресурсы типа картинок, стили лучше подключать из css файлов прямо в теневое дерево элемента.
просто надо учитывать, что html это динамическая среда, компоненты могут не только произвольно появляться, но и также исчезать из контекста браузера, поэтому они должны быть друг от друга максимально независимы, даже если образуют иерархию и взаимодействовать несвязывающими способами
компоненты могут выбрасывать эвенты вида «я загрузил данные», другие компоненты могут на них подписываться и начинать работать только вовремя без таймаутов. Технологии вебкомпонентов как раз хороши в том, что оно впервые за 20 лет развития фронтенда позволяет добиться такой работы без setTimeout.
если вы используете свою кнопку зарегистрированную customElements, значит без JS уже не обошлось. api браузерных элементов закрыт для изменений, но открыт для расширения. Формы можно программно сабмитить с помощью FormData. Если у вас своя кнопка, то компонент формы тоже может быть целесообразно создать свой.
Rx и подобные вещи хороши пока вы код одного применения умещается на экране. Вот например вам надо сделать реализацию дранэндропа или обрабатывать ввод поля ввода. Для этого надо взаимодействовать сразу с последовательностью событий, т.е. взять 3 и если там что-то подошло под критерий (есть все из: драгстарт, драгмув, драгенд) обработать, тут rx будет удобнее и изящнее, потому что выражение примерно так и будет записано как: стрим.взять(3).офильтровать(условие).выполнить(код).запуск().
Mobx тут вероятно может быть использован как rx и тогда не ясно зачем он нужен вообще. Стримы скорее всего со временем добавят в язык и rx тоже станет лишним.
Альтернативно, он может быть использован аналогично императивному подходу с хранением промежуточных состояний, что практически всегда хуже и фактически сложнее, т.к. потребует явной проработки множества кейсов.
в CMS WordPress написанном на процедурном пхп4, что-бы поменять лейаут страниц (2 колонки на 3) надо хачить код на помеси хтмл и пхп прямо в темах
а в CMS LifeRay это делается в настройках лейаута страницы (или можно программно).
и у каждого свои ещё, отсутствие исключении и дженериков всегда будет удерживать код на го на уровне перла или пхп из 90х, от которых все стремительное сбегали потом
ну прежде всего отсутствие классического ООП с наследованием, примеси в этом ключе точно также превращают код в помойку артефактов понять взаимосвязи которых очень сложно без поллитры и дебагера
С++ изобрели потому, что проекты на си т е без ООП почти всегда вырастали в помойки которые невозможно развивать и даже поддерживать сложно, у молодежи этого понимания нет им проще писать функции чем думать о полиморфизме и солиде, поэтому клоны си без классов и наследования, порождающие такие же безнадёжные помойки, но не сразу и в условиях дикой ротации кадров не важно, заходят ну и конечно просто в их раскрутку вваливаются огромные ресурсы, а диланг например всегда был сам по себе
как это не странно, но кажется им надо было астановится в добавлении новых штук, стабилизировать апи и накопить библиотек и фреймворков под типичные задачи. Но просто собирать утилитарный код на dlang не всегда удавалось даже скорее всегда не удавалось. Го и раст лоббируются комерсами, чтобы подставлять питонистов с пхпшниками, дальше инфраструктур компаний эмиграционных конвейеров где нужны регулярные скандалы с увольнениями они в силу заложенных дефектов не уедут.
без классов оно не так уж better, c++ всегда был в первую очередь "си с классами", зачем делают новые языки, такие как раст и го под ржавчину времен настоящих мужчин не очень понятно, точнее конечно есть гипотеза, что это чтобы они не конкурировали джаву с сишарпом, а формировали фрик гетто принципиально бестолковое, которое само будет разбиваться при попытке создать что-нибудь по настоящему стоящее в любой нише. Но очередной "убийца си" без классов устойчиво расстраивает простого, но опытного быдлокодера.
что-то из микрософтовского семейства, теперь это не актуально уже конечно
innerHTML не во всех браузерах или вообще не вызывает рендер кастомных элементов, а в этом тут вся магия