Да, все так. Просто далее часть выражения [,,~1]() (еще 1()) показалась более интересной для этого замечания о корректности выражения с точки зрения парсера и ошибки при исполнении. Спасибо за внимательность!
request тянет кучу ненужных зависимостей, тогда как сейчас нужно просто отправить GET-запрос за контентом и заголовками:
«Покрывает 2ой пункт» — в смысле, обходит редиректы? это как раз умышленно не происходит, чтобы руками собрать все цепочки и использовать более-менее общий алгоритм экстрактора.
Нативных клиентов для задачи — достаточно. В дальнейшем да, got (который полегче) кажется хорошим вариантом… чтобы те же ретраи и таймауты организовать.
И есть ли смысл использовать JSDOM для данной задачи?
Если есть альтернативы полегче, буду рад идеям! Задача сводится к парсингу контента для дальнейшего простого поиска элементов дерева по атрибутам и их значениям.
Да, у нас в компании есть краулеры как минимум на C/C++, Java. Но определенно это не то место для более подробной информации ) Настоящий материал имеет ознакомительный характер, цель которого — рассказать об основных моментах, с которыми имеешь дело вне зависимости от выбранного языка. Если же интерес вызван потенциальным желанием принять участие в разработке, то всегда можно откликнуться, прийти и узнать подробности )
Да, ситуация несколько досадная. Учитывая, что часто 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.
Идея в том, что JavaScript позвляет это сделать без усилий в большинстве случаев. А на той, другой стороне как минимум две проблемы: 1) часто это строгие и не динамические языки и 2) на серверной стороне слишком много языков.
«Покрывает 2ой пункт» — в смысле, обходит редиректы? это как раз умышленно не происходит, чтобы руками собрать все цепочки и использовать более-менее общий алгоритм экстрактора.
Нативных клиентов для задачи — достаточно. В дальнейшем да, got (который полегче) кажется хорошим вариантом… чтобы те же ретраи и таймауты организовать.
Если есть альтернативы полегче, буду рад идеям! Задача сводится к парсингу контента для дальнейшего простого поиска элементов дерева по атрибутам и их значениям.
В этом тоже есть некоторая здравость… даа. Придется использовать внешние либы.
— для больших числовых идентификаторов
— для точных меток времени
— для реализации BigDecimal
Да, ситуация несколько досадная. Учитывая, что часто JavaScript — не единственный язык, на котором приходится писать… и в нем все больше и больше специфики.
Возможно, многие читали этот issue о кейворде: там довольно много обсуждения и недовольств.
Think of what you might need to do to make that work.
Это просто синтаксис меньшего зла ) комментарий по этому поводу
Можно указать переменную, да… попробуйте )
Это очень полезная штука ) на него не было наезда: там про сохранение контекста this или про расширение свойств экземпляра класса в конструкторе.