Поддержка области JS в вызове конструктора Custom Element
Я экспериментировать с новой выкройкой,
где каждый вновь созданный элемент карты
использует область constructor для хранения (частных) переменных:
псевдокод:
class CardtsCard extends HTMLElement {
constructor(){
let private = 666;
Object.assign(this,{
getPrivate : () => console.info(private)
});
}
get private(){
//can not access scope in constructor
return 42;
}
}
Так:
el.getPrivate(); // outputs 666
el.private; // outputs 42
I have loads of getters and setters
and sticking data ON my elements with
this.whatever=value feels a bit weird.
Я могу расширить его до:
class CardtsCard extends HTMLElement {
constructor(){
let private = new Map();
Object.assign(this,{
setPrivate : (data,value) => private.set(data,value),
getPrivate : (data) => private.get(data)
});
}
}
Вопрос: Я не эксперт по JS, есть ли недостатки?
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 1
Всякий раз, когда вы вызываете конструктор в первом примере, необходимо создать замыкание, содержащее эти «частные» переменные. Для нескольких элементов это не вызывает каких-либо накладных расходов, но для большого количества элементов вы можете столкнуться с накладными расходами по производительности и памяти.
Что касается вашего второго примера: Map поиск не может быть встроен, поиск свойств может, поэтому он более эффективен (что вы заметите только во многих операциях).
И какую выгоду вы получаете от этой установки? Публичный метод getPrivate не является приватным, не так ли? Если вам нужны приватные переменные, пометьте их каким-то образом как приватные и доверьте всем, кто использует код, обращаться с ним надлежащим образом.
@supersharp Я хочу увидеть тестовый пример, где это правда.
Так сфера есть сфера? Карта внутри (IIFE) такая же, как Карта внутри конструктора?? Любые указатели на «Карта и встроенный» ?? Первый гуглинг дает мне больше технических вещей по Java (я отказался изучать это четверть века назад)
@danny, в конце концов, constructor — это просто функция (хотя и особенная). Если вы посмотрите «Скрытый класс V8», вы найдете больше оптимизаций, связанных с JS. Или просто кликните сюда
Tnx Джонас, это (моя) домашняя работа: richardartoul.github.io/jekyll/update/2015/04/26/…
@Jonas Wilms есть много примеров на jsperf. В любом случае производительность будет гораздо больше зависеть от техники кодирования автора, JS-движка и профиля процессора, чем от различий между замыканием и классами. И, как вы сказали, в большинстве случаев это не вызывает никаких накладных расходов.
На самом деле иногда нет накладных расходов на производительность, но прирост производительности при использовании частной (замыкающей) переменной по сравнению с объектной переменной