Pull to refresh

Comments 14

Есть же асинхроннвя проверка доступности через let (или setTimeout, если по старинке). Модули все можно через неё грузить, а по загрузке вешать обработчики/хуки. Это стандартный шаблон асинхронного дизайна взаимодействия.

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

Второе, setTimeout не гарантирует, что функция вызовется после указанной задержки, скажем в 200 ms. Он лишь кидает функцию в очередь сообщений. В эту очередь могут попасть и другие функции-обработчики. Кроме того, если после него поставить что-то, что будет вычисляться долго, то задержка превысит указанное время ожидания.

Классы можно реализовать с помощью функций конструкторов, если не брать в расчёт современные стандарты (ES6). Будем реализовывать класс вручную.

Чем это оправдано? У классов сейчас 96% поддержки.

Вы зачем-то так сконцентрировались на классах и их реализации, хотя это банальная вещь и не имеет отношения к библиотеке.

Чтобы динамически определять классы с помощью функций и объектов-параметров.

В ReactJS используются классы. Но там да, классы определяются современным синтаксисом. А для динамики можно использовать class-expressions. Но тут стояла необходимость устранить дубли кода при проверке аргументов конструктора класса, а также реализовать автоматический вызов конструктора родителя, без явного вызова super().

В самих классах нет ничего плохого, они используются повсеместно. И они уже есть в js и выдумывать их заново не нужно. Просто используйте их, в них вопросы о которых вы пишете давно решены.

Хорошо. Просто тематика статьи была не про "современные решения" а ad hoc решения, написанные вручную.

Хорошо!
Я вернусь к этой статье, когда забанят возможность пользоваться готовыми фреймворками

Давайте использовать устаревший синтаксис, но, при этом, не поддерживаемый в IE, чтобы потом закостылить свои модули и классы... Затем напишем кучу лапши... ЗАЧЕМ? Вы всерьез пытаетесь кого-то чему-то научить?

Особенно странно на фоне заявления о несовместимости с IE выглядят проверки, где что-то на IE всё-таки проверяется (типа User-Agent'а).

В дисклеймере указано, что синтаксис не современный. Поскольку тематика статьи не современные решения, а ad hoc решения. Т.е. а что делать, если у нас браузер не поддерживает современный синтаксис, а пересаживаться на новые версии лень.

Что же касается IE, то о нём пойдет речь в следующей части статьи.

Зачем писать о IE в следующей статье? Этот браузер МЕРТВ, окончательно и бесповоротно. Его давно списали даже сами его разработчики, доля его использования в общем трафике - микроскопическая, на уровне погрешностей, и продолжает уверенно стремиться к нулю. Зачем кому-то может понадобиться инвестировать свое время в исчезнувшую платформу? Ради чего?

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

Это какой именно браузер его не поддерживает? ES6+ поддерживают ВСЕ актуальные браузеры, уже ОЧЕНЬ давно. Вам еще нужно сильно постараться, чтобы найти некробраузер, которые умеет только в ES5, не умеет в классы и модули. А еще вы можете, если вам все-таки сильно приспичит, преобразовать свой код в ES5 в любой момент с помощью Babel.

Пожалуйста, изучите современные технологии и стандарты, прежде чем давать людям какие-либо советы и рекомендации, иначе это выглядит как уроки по созданию каменного топора от покрытого мхом динозавра. Для реализации библиотеки виджетов, вам понадобятся Shadow DOM и Custom Elements. Еще вам понадобится стандарт ESM.

Так-то да. Но статья была о том, что у нас этого вообще нет. И мы не хотим это скачивать и разбираться. А хотим строить своё ad hoc решение. Которое не идеальное, что указано в статье. Которое ещё нужно дорабатывать, и не раз. Это про трудный, тернистый, бесполезный путь virgin разработчика.

Sign up to leave a comment.

Articles