Неожиданный порядок инициализации наследованных классов в JavaScript

Python.

Неожиданный порядок инициализации наследованных классов в JavaScript

Как обычно набежала куча любителей самоутверждения чтения документации. Хабру явно не хватает возможности отключать комментарии.

v1vendi на многих ЯП ты бы получил ожидаемый результат:

class BaseTooltip:
    template = 'baseTemplate'

    def __init__(self, content):
        self.render(content)

    def render(self, content):
        print('render:', content, self.template)

BaseTooltip('content')

class SpecialTooltip(BaseTooltip):
    template = 'otherTemplate'

SpecialTooltip('otherContent')

# render: content baseTemplate
# render: otherContent otherTemplate

, плюс все (которые я видел) обёртки имитирующие классы до ES6 вели себя именно так. Я тоже когда-то попался на этом хоть и заглядываю в спецификацию.

UPD: одно из решений — использование статических свойств с обращением к ним через this.constructor.

Улучшайте свое знание JavaScript разбирая исходный код

А как же PrototypeJS и MooTools? Я довольно прилично прокачал свои знания js именно за счёт изучения внутренностей PrototypeJS.

Почему я не использую веб-компоненты

В общем, я свою точку зрения высказал, принимать что-то или нет — дело твоё. Дальше препираться смысла не вижу, по моему опыту это не приводит ни к чему кроме потери времени. Удачи!

Почему я не использую веб-компоненты

вам всё равно придётся открывать кучу веток этих самых кишок

не прийдётся. Не обязательно и может даже не нужно обычные въюхи в ShadowDOM запихивать, он обязательно используется только для компонент вроде селекта, табов и подобного. Но кишки мешают больше не мне в devtools, а как раз при использовании таких компонентов в других фреймворках самим этим фреймворкам.

Не использоваться фреймворки, которые сложно друг с другом интегрировать.

ага, вот и я как раз про это: фреймворки на основе веб-компонентов максимально безболезненно интегрируются друг с другом. Причём это вполне естественно и не выглядит как совмещение единорога с китом. Сейчас интеграция заключается лишь в том, чтобы подружить полифилы, когда они станут не нужны, никакой интеграции вообще не нужно будет.

Почему бы ей не захотеть не только единый стиль, но и единое поведение, и единую реализацию, и единый фреймворк?

веб-компоненты с большой вероятностью проживут намного дольше, чем любой из существующих сегодня фреймворков, так зачем привязывать себя к какому-то из них, ждать когда он отомрёт и по новой переписывать каждую рюшечку? Если ui-библиотека сделана на веб-компонентах, то пусть разработчики использующие её пишут на чём им удобно.

Ну конечно, и ленивый реактивный рендеринг к ним легко прикрутить?

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

Не усложнит.

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

Это какие? Когда я последний раз смотрел — их все задепрекейтили.

ну видимо когда-то предложат что-то на замену или достаточно того, что осталось, я сейчас больше про общую идею, а не про текущую её реализацию, которая пока да, не идеальна. Сам я из веб-компонентов использую только CustomElements и HTMLTemplates. ShadowDOM полноценно не полифилится, а существующие недополифилы сильно жрут производительность. Поэтому я не особо в курсе что там с селекторами. Использую привычный БЭМ.

о чём вы

применяйте

я себя лет на 20 старше чувствую)). Зачем вообще на хабре все выкают? В офисах и на конференциях все на ты, а здесь ощущение, как будто сплошные доктора наук собрались).

Почему я не использую веб-компоненты

Насчёт кишок я не понял о чём вы

я про внутренний dom компонента, зачем он мне торчащий наружу.

Неймспейсы и маглинг имён решают проблему конфликтов не хуже изоляции.

хуже, глобальные стили протекают внутрь компонента.

Представь ситуацию: крупная компания, количество фронтенд-команд перевалило за десяток, каждая сама выбирает удобный ей фреймворк и базовый набор стилей. Можно, конечно, определить корпоративный стандарт, но это существенно усложнит поиск новых разработчиков. Кроме того проекты достаточно долгоживущие, фреймворки отмирают быстрее. При этом компания хочет свой корпоративный стиль, свои компоненты, отличающиеся от стандартных, часто не только цветом. Что делать? Разрабатывать и поддерживать библиотеки компонентов под каждый используемый фреймворк? Дороговато выходит.
Или другая ситуация: ты работаешь в компании A и разрабытываешь библиотеку компонент на фреймворке X. А потом либо меняется компания A и в компании B используется фреймворк Y, либо фреймворк X отмирает и все хотят Y. Куча работы вылетает в трубу, а ведь класный набор компонентов получился, хотелось бы дальше применять.
Веб-компоненты тут идеальное решение, ShadowDOM спрячет лишний внутренний dom, который теперь не будет мешать фреймворкам, глобальные стили не будут заставлять компонент расползаться, но, в то же время, есть хитрые css-селекторы позволяющие при необходимости что-то поменять внутри. Другими словами, получающиеся компоненты полностью автономны, так же как и уже встроенные в браузер input, select, video и тд. Из коробки веб-компоненты не очень удобны, но большинство существующих проблем решается легковесной обёрткой, опять же никак не мешающей существующим фреймворкам.

Почему я не использую веб-компоненты

Как с помощью библиотек реализовать элемент с изолированным css и не торчащими наружу кишками (ShadowDOM)?

Почему я не использую веб-компоненты

тормоза лейаута после ресайза

если у вас лейаут считается в js-e, то это будет тормозить на любом фреймворке.

Svelte 3: Переосмысление реактивности

Выше уже разобрались, что $$invalidate ставится только для переменных используемых в шаблоне и реактивных объявлениях. Всё норм)

Svelte 3: Переосмысление реактивности

только для переменных, которые задействованы в шаблонах

да, тоже подумал об этом после отправки сообщения. Тогда всё норм, единственно что переменная может использоваться в шаблоне, но быть внутри условия, которое сейчас неактивно. Тогда $$invalidate сработает, но вряд ли там что-то страшное (изменение DOM) произойдёт.

Svelte 3: Переосмысление реактивности

Разве не будет ситуаций когда эти $$invalidate ставятся там где совсем не надо? Если уж есть свой компилятор, то почему бы не ввести новое ключевое слово? Например, я когда-то делал плагин для babel который заменял такой код:

cell firstName = 'Matroskin';
cell lastName = 'Cat';

cell fullName = firstName + ' ' + lastName;

console.log(fullName);

на такой:

const cellx = require('cellx');
const firstName = new cellx.Cell('Matroskin');
const lastName = new cellx.Cell('Cat');

let fullName = new cellx.Cell(() => firstName.get() + ' ' + lastName.get());

console.log(fullName.get());

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

Как реализовать язык программирования на JavaScript. Часть 1: Парсер

Благодарю, пригодится.

Как реализовать язык программирования на JavaScript. Часть 1: Парсер

Ну поменять так:

const reSuperCall = RegExp(`super(?:\\.(${namePattern}))?!|`, 'g');

Вообще как только что-то усложняется, ничто не мешает делать без регулярок. В примере выше имя больше нигде не повторялось, мне не было смысла отделять его от super, но в соседнем парсере повторялось и _readName ниже использовался в этих местах, написанных уже как обычно:

const reName = RegExp(namePattern + '|', 'g');

    _readName(): string | null {
        reName.lastIndex = this._pos;
        let name = reName.exec(this.contentNodeValue)![0];

        if (name) {
            this._pos = reName.lastIndex;
            return name;
        }

        return null;
    }

Как реализовать язык программирования на JavaScript. Часть 1: Парсер

мы будем обязаны изменять все регулярные выражения, а не одну функцию

зачем?

Как реализовать язык программирования на JavaScript. Часть 1: Парсер

Не пробовать использовать регулярных выражений для парсинга. Они просто не работают.

Много разных парсеров написал подобным образом, с регулярками сначала действительно не понятно было как их применять даже там где они казалось бы в тему. Там проблема собственно в том, что регулярка не найдя совпадение в нужной позиции начинает искать его на следующих. Можно обрезать строку и использовать ^, но постоянные обрезания огромной строки плохо влияют на карму парсера. Придумал вариант с добавлением в конец регулярки | — если на первой позиции совпадение не найдено, происходит гарантированной совпадение с пустотой, ну и проверяем match[0], если пусто, то совпадения нет. Пример:

const reSuperCall = /super(?:\.([a-zA-Z][\-\w]*))?!|/g;

    _readSuperCall(): ISuperCall | null {
        reSuperCall.lastIndex = this._pos;
        let match = reSuperCall.exec(this.template)!;

        if (match[0]) {
            this._pos = reSuperCallOrNothing.lastIndex;

            return {
                nodeType: NodeType.SUPER_CALL,
                elementName: match[1] || null
            };
        }

        return null;
    }

Это мелочь конечно, но может кому-то пригодится, так как ситуации когда хочется скатиться к регулярке довольно часто бывают.

И второе: функциональный стиль здесь действительно удобен, но посмотрите ещё раз пример с InputStream — в нём нужно каждой функции передавать общее состояние, это организуется через замыкание и для этого внутри функции при каждом вызове создаётся множество других функций и чем сложнее парсер, тем их будет больше. Если один в один переписать в виде класса (общее состояние будет в this или просто без класса передавать его каждый раз в переменной), то производительность резко подскакивает. В некоторых случаях в десятки раз.

Maraquia — ORM для MongoDB

Добавил.

Веб-компоненты в реальном мире

только если они не имеют своих зависимостей

Ладно, убедили), проблема есть, но всё же при использовании префиксов она совсем незначительна.

Здесь помог бы typescript

Не на 100%, как я уже сказал, браузеры могут добавлять свои нестандартные свойства/методы для элементов.

Веб-компоненты в реальном мире

Может хорошей практикой считать не регистрировать компоненты в UI-библиотеках, просто экспортировать класс и пусть использующий сам регистрирует под нужным ему именем. Я все компоненты сам писал так что такой проблемы не было, была проблема с именами атрибутов-свойств: уже существующих свойств дофига, у разных элементов они немного отличаются, плюс немного отличаются от браузера к браузеру. В результате можно легко переопределить существующее имя и получить какой-нибудь непонятный баг.

Веб-компоненты в реальном мире

Обычно элементам добавляется какой-то префикс, например здесь добавляют paper.

Веб-компоненты в реальном мире

вы ничего уже с этим сделать не сможете

Можно унаследовать от такого компонента с изменением имени.