Комментарии 14
Есть же асинхроннвя проверка доступности через let (или setTimeout, если по старинке). Модули все можно через неё грузить, а по загрузке вешать обработчики/хуки. Это стандартный шаблон асинхронного дизайна взаимодействия.
Так тут стояла задача сделать это синхронно на тот случай, если после данного скрипта, в разметке сразу идут другие, которые его используют. Можно, конечно, организовать всё асинхронно, и подгружать скрипты в строгом порядке. Тогда надо убрать зависимые скрипты из разметки и поместить их загрузку в хуки. Но замес в том, что скрипты должны быть загружены после разбора документа, а не в любое доступное время. Тогда нам надо вешать хук на onload для страницы, который начнёт загрузку скриптов библиотеки.
Второе, setTimeout не гарантирует, что функция вызовется после указанной задержки, скажем в 200 ms. Он лишь кидает функцию в очередь сообщений. В эту очередь могут попасть и другие функции-обработчики. Кроме того, если после него поставить что-то, что будет вычисляться долго, то задержка превысит указанное время ожидания.
Классы можно реализовать с помощью функций конструкторов, если не брать в расчёт современные стандарты (ES6). Будем реализовывать класс вручную.
Чем это оправдано? У классов сейчас 96% поддержки.
Вы зачем-то так сконцентрировались на классах и их реализации, хотя это банальная вещь и не имеет отношения к библиотеке.
Чтобы динамически определять классы с помощью функций и объектов-параметров.
В ReactJS используются классы. Но там да, классы определяются современным синтаксисом. А для динамики можно использовать class-expressions. Но тут стояла необходимость устранить дубли кода при проверке аргументов конструктора класса, а также реализовать автоматический вызов конструктора родителя, без явного вызова super().
Хорошо!
Я вернусь к этой статье, когда забанят возможность пользоваться готовыми фреймворками
Давайте использовать устаревший синтаксис, но, при этом, не поддерживаемый в IE, чтобы потом закостылить свои модули и классы... Затем напишем кучу лапши... ЗАЧЕМ? Вы всерьез пытаетесь кого-то чему-то научить?
Особенно странно на фоне заявления о несовместимости с IE выглядят проверки, где что-то на IE всё-таки проверяется (типа User-Agent'а).
В дисклеймере указано, что синтаксис не современный. Поскольку тематика статьи не современные решения, а ad hoc решения. Т.е. а что делать, если у нас браузер не поддерживает современный синтаксис, а пересаживаться на новые версии лень.
Что же касается IE, то о нём пойдет речь в следующей части статьи.
Зачем писать о IE в следующей статье? Этот браузер МЕРТВ, окончательно и бесповоротно. Его давно списали даже сами его разработчики, доля его использования в общем трафике - микроскопическая, на уровне погрешностей, и продолжает уверенно стремиться к нулю. Зачем кому-то может понадобиться инвестировать свое время в исчезнувшую платформу? Ради чего?
а что делать, если у нас браузер не поддерживает современный синтаксис
Это какой именно браузер его не поддерживает? ES6+ поддерживают ВСЕ актуальные браузеры, уже ОЧЕНЬ давно. Вам еще нужно сильно постараться, чтобы найти некробраузер, которые умеет только в ES5, не умеет в классы и модули. А еще вы можете, если вам все-таки сильно приспичит, преобразовать свой код в ES5 в любой момент с помощью Babel.
Пожалуйста, изучите современные технологии и стандарты, прежде чем давать людям какие-либо советы и рекомендации, иначе это выглядит как уроки по созданию каменного топора от покрытого мхом динозавра. Для реализации библиотеки виджетов, вам понадобятся Shadow DOM и Custom Elements. Еще вам понадобится стандарт ESM.
Создаём свою библиотеку виджетов на Javascript голыми руками. Часть 0: Классы и модули