Pull to refresh
29
0
Antony Belov @cerberus_ab

JavaScript Apologist

Send message
Нее, просто иногда хочется поразвлечься… тем более на конференции, где и без того очень много практической составляющей на докладах )
Да, все так. Просто далее часть выражения [,,~1]() (еще 1()) показалась более интересной для этого замечания о корректности выражения с точки зрения парсера и ошибки при исполнении. Спасибо за внимательность!
Спасибо большое за наводку!
request тянет кучу ненужных зависимостей, тогда как сейчас нужно просто отправить GET-запрос за контентом и заголовками:

image

«Покрывает 2ой пункт» — в смысле, обходит редиректы? это как раз умышленно не происходит, чтобы руками собрать все цепочки и использовать более-менее общий алгоритм экстрактора.

Нативных клиентов для задачи — достаточно. В дальнейшем да, got (который полегче) кажется хорошим вариантом… чтобы те же ретраи и таймауты организовать.

И есть ли смысл использовать JSDOM для данной задачи?

Если есть альтернативы полегче, буду рад идеям! Задача сводится к парсингу контента для дальнейшего простого поиска элементов дерева по атрибутам и их значениям.
Да, у нас в компании есть краулеры как минимум на C/C++, Java. Но определенно это не то место для более подробной информации ) Настоящий материал имеет ознакомительный характер, цель которого — рассказать об основных моментах, с которыми имеешь дело вне зависимости от выбранного языка. Если же интерес вызван потенциальным желанием принять участие в разработке, то всегда можно откликнуться, прийти и узнать подробности )
Спасибо! надеюсь буду располагать временем )
Спасибо! Согласен, что проблема именно в десериализации. Просто защитились от возможной неоднозначности еще одним TypeError.
Отдельно хотелось бы добавить еще ложечку дегтя: bigint вызывает ошибку сериализации при JSON.stringify:

let data = { x: 1n };
JSON.stringify(data); // TypeError: Do not know how to serialize a BigInt

В этом тоже есть некоторая здравость… даа. Придется использовать внешние либы.
BigDecimal на базе BigInt :)
Собственно, про это уже писали:
— для больших числовых идентификаторов
— для точных меток времени
— для реализации BigDecimal
Уже кто-то шутил про собачку для protected полей :)
Тоже об этом подумал ) Но синтаксис приватных полей класса работает только внутри тела определения класса.

Да, ситуация несколько досадная. Учитывая, что часто JavaScript — не единственный язык, на котором приходится писать… и в нем все больше и больше специфики.


Возможно, многие читали этот issue о кейворде: там довольно много обсуждения и недовольств.


Например, мол сложно внедрять

Think of what you might need to do to make that work.


  • You'd have to somehow encode a "private key" into each lexical environment.
  • You'd have to change the semantics of each and every property access (because any property access might result in a private field). Engines are highly optimized around the current property lookup semantics.
  • Would for-in enumerate over these properties?
  • Can someone shadow a private property with a normal property lower on the prototype chain? What about the reverse?
  • How do you prevent leaking the names of private fields to clients that shouldn't know that information? This is probably a fatal information leak.

Это просто синтаксис меньшего зла ) комментарий по этому поводу

только c — неизвестная. наверно там placeholder? )
Да, почему бы и нет! spread operator ничего не нарушает )
eval я умышленно обошел стороной.
Можно указать переменную, да… попробуйте )
Спасибо, исправил!
Идея в том, что JavaScript позвляет это сделать без усилий в большинстве случаев. А на той, другой стороне как минимум две проблемы: 1) часто это строгие и не динамические языки и 2) на серверной стороне слишком много языков.

Это очень полезная штука ) на него не было наезда: там про сохранение контекста this или про расширение свойств экземпляра класса в конструкторе.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity