JavaScript: хочу свой HTMLElement

[zababurin]

Лучше посмотреть на то, что бы сделать базовый абстрактный компонент, от которого наследоваться остальным компонентам. И можно под себя полноценный фреймворк сделать.

[wentout]

Да, с React Component тоже самое можно провернуть )

[zababurin]

Ну в реакте это лишнее. Там как правило это стейт менеджер какой нибудь. Да и в целом виртуальное дерево это заменяет.

Реакт это уже фреймворк(знаю что это библиотека) а здесь ты сам создаешь то что требуется. Можно и реакт свой условно собрать. Я хуки(не помню как это называется useEffect useState) на компонентах делал как то.

[wentout]

Да, там достаточно просто от компонента унаследоваться, и вобоще не иметь дело с остальной их обвязкой с тими props и т.п., если хочется просто как шаблонизатор его использовать чтобы "на коленке" велосипед собрать )

[zababurin]

Я бы сказал, можно структуру проекта не учитывать вычеркнув её из проекта. Я ни одного такого велосипеда не видел.

[wentout]

Проект, в котором только свои собственные тёпленькие компоненты + немного спагетти-макаронной логики для обвязки. Пишется быстро, разбираться потом невозможно. Но нужно ли )

[zababurin]

Проект, в котором только свои собственные тёпленькие компоненты + немного спагетти-макаронной логики для обвязки. Пишется быстро, разбираться потом невозможно. Но нужно ли )

Здесь нет ни одного правильного слова.

1. Макаронной логики для обвязки не надо.- в этом и фишка компонентов.
2. Пишется быстро, - Придумать сложно.
3.  разбираться потом невозможно - 1 файл 400-500 строчек кода элементарного кода + это стандарт html который вы знать должны (вы React и остальные 100 500 фреймворков можете не знать ).. А вы точно программист ? Сказать что это сложно это сказать я не знаю html это для меня сложно.
https://developer.mozilla.org/ru/docs/Web/API/Web_components/Using_custom_elements
4. Но нужно ли. - Гарантия что я могу собрать проект за 2 недели определенной сложности мне нравится. Вам не знаю.

[wentout]

Предыдущй мой коментарий -- это сарказм )

В API Custom Elements ни слова про Proxy.
API для отслеживания свойств в DOM совсем другое, и к JS имеет такое же отношение, как customElements.define , мне всё же хотелось в примере быть ближе именно к JS.

А вообще я Back-End пишу на Node.js, в браузер смотрю для чтения статей, решил, вот написать что-то, что может быть кому-то интересно, т.к. прикладные навыки с Front-End остались в эпохе jQuery.

[zababurin]

А я про   Апи ничего и не писал... Я писал. При чем здесь оно ?... Я сервер написал пару месяцев назад, все руки не доходят его подключить. Слава богу о нем никто и не вспоминает пока ))

[wentout]

эмм... наверное потому, что без customElements.define не получится сделать, т.к. нужно зарегистрировать кастомный HTML элемент, иначе придётся модифицировать базовые, а это не то, чтобы вообще правильно, не знаю, может попробую когда-нибудь поэксперементировать, вообще, скорее всего, можно и их модифицировать, там нет рекурсии, конечное количество глубины, просто, вот это точно громадный impact по производительности будет, но если там нет запретов, то можно порвать и эти цепочки

Современный Front-End где нужно знать 100500 библиотек и фреймворков только чтобы страничку отрендерить -- это сложно, переусложнено. Нужно было как-то на реакт что-то сделать очень простое. С .props было лень разбираться, со стейтами и т.п., прям лень. Добавил общую зависимость, подписался на неё и вызывал .render по мере необходимости. Коряво, но элементарно, уложился в пару часов. Но вообще да, всё браузерное API выучить, видимо, уже практически не реально, разве что если писать это самое API со стороны писателей API или стандартов, то есть когда это работа. Видимо поэтому все библиотеки и плодятся, упрощая работу в какой-то своей привычной авторам "атмосфере".
А так Custom Elements -- это тоже своего рода API -- то есть Application Programming Interface )

[zababurin]

Не понимаю о чем мы говорим уже. В общем компоненты это круто и просто.С компонентами я динамически могу любой сложности проекты делать. Это быстрее чем со всем остальным и мне хорошо.

[ooko]

В реакт убили компонентный поход. Теперь там за все отвечает родитель, а на практике глобал)

[nihil-pro]

Только зачем Proxy, если у HTMLElement уже есть методы setAttribute, removeAttributе которые можно переопределять + есть attributeChangedCallbak + MutationObserver чтобы отслеживать вложенные элементы? HTMLElement это очень большой объект, и его проксирование это очень дорогая операция.

[wentout]

Да, просто если хочется видеть сами вызовы .setAttribute и .removeAttributе и т.п., то можно и так, думаю. Про размер объекта -- не уверен, что это как-то влияет, объект --это же всего лишь указатель, поэтому какая разница что там "под" прокси. Количество свойств, безусловно влияет если мы хотим их "перебирать", но они же все в этом самом объекте, то есть хешированы и доступ к ним "атомарный". Другое дело, что в самом деле само проксирование -- дорогая операция + поиск свойств вглубину же будет, и чем на более низжем уровне они лежат, тем дольше. А так -- да, конечно, спасибо за дополнение!

[nihil-pro]

Да, просто если хочется видеть сами вызовы .setAttribute и .removeAttributе и т.п., то можно и так

А что еще вы хотите видеть, а самое главное зачем?

Класс HTMLElement наследует класс Element. И в одном и в другом примерно два-три свойства, все остальное пара getter/setter (за исключением readonly свойств, там только getter), следовательно у вас уже есть механизм перехвата чтения/записи без необходимости проксировать

class MyHTMLElement extends HTMLElement {
  get innerText() {
    // кто-то прочитал innerText
    return super.innerText
  }

  set innerText(value) {
    // кто-то хочет зменить innerText
    return super.innerText = value;
  }
}

Конечно браузеры не могут полностью защитится от таких попыток влезть туда, куда не стоит, но в этом случае они довольно строго предупреждают:

class MyHTMLElement extends HTMLElement {
  constructor() {
    super();
    return new Proxy(this, {});
  }
}

TypeError: custom element constructors must call super() first and must not return a different object

TypeError: Failed to execute 'createElement' on 'Document': The result must implement HTMLElement interface

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

[wentout]

Думаю не представляет никакого интереса. Уверен они точно знают, что так можно и в этом нет ничего такого уж необычного. Выйти "за границы" не получится, оно всё равно в рамках JavaScript останется, а "базовую логику" я не трогал, просто инкапсулировал. Полиморфизм добавлен "сверху", без мутации, так что смысла в споре не вижу.

Зачем ? Практического смысла не много, да и вряд-ли кто-то после прочтения статьи прям "бросится" писать код на основе этой идеи. В вашем примеме радикальных отличий от моего примера только те, что Proxy у вас не используется. Так что спорить смысла тоже не вижу )

А, ну и да, вы же неправильно сделали, поэтому и получили ошибку, вот так нужно:

class MyHTMLElement extends HTMLElement {
  constructor() {
    super();
    const root = Object.getPrototypeOf(this);
    const props = {
      // тут можно дополнительных свойств накидать
      // которые нужно проксировать
    };
    Object.setPrototypeOf(props, root);

    // в этом месте в this можно накидать свойств
    // которые не будут обрабатываться proxy
    
    const proxy = new Proxy(props, { ... });
    Object.setPrototypeOf(this, proxy);

    // а с этого места всё новое в this будет идти через proxy    
  }
}

Если так сделаете то вашей ошибки не будет )