Comments 49
Самые полезные модули эти, встречайте хитпарад:
is-string — пол миллиона с хвостиком скачиваний за последние 7 дней(https://www.npmjs.com/package/is-string)
is-odd — почти 3 миллиона (https://www.npmjs.com/package/is-odd)
И! Наш лидер!
is-number — почти 10 миллионов скачиваний за последнюю неделю (https://www.npmjs.com/package/is-number)
А вы говорите ;)
is-string — пол миллиона с хвостиком скачиваний за последние 7 дней(https://www.npmjs.com/package/is-string)
is-odd — почти 3 миллиона (https://www.npmjs.com/package/is-odd)
И! Наш лидер!
is-number — почти 10 миллионов скачиваний за последнюю неделю (https://www.npmjs.com/package/is-number)
А вы говорите ;)
+3
О них и так все знают. А статья о тех, о которых стоит узнать.
-2
UFO just landed and posted this here
Видимо ни одной статьи о node модулях не обойдется без шуточки об этих модулях. Ха-ха.
А что вы предлагаете взамен? Писать вот эту магию приведения к числу каждый раз заново?
+1
Если я не ошибаюсь, всю его магию можно сократить до:
Number.isFinite(Number(num));
0
На самом деле есть две функции isFinite()
Number.isFinite()
– не работает для строк, содержащих числа, напримерNumber.isFinite('123')
вернет false- глобальная функция
isFinite
. Она вернет true для случая из примера выше, но все равно имеет проблемы, напримерisFinite([])
тоже вернет true, хотя очевидно, что это не число.
Вот так и получается, что иногда нужен именно пакет is-number.
0
Интересно и полезно. Как только сдохнет не православный require и появится нормальный import я начну использовать node.js :)
-1
А ключ --experimental-modules на что?
0
Хм. Я вообще не смотрел еще. Пару раз установил, побаловался — удалил. Я думаю о том, что после production релиза можно будет принимать решение, что именно использовать. Это будет то, что работает на import(это будет значить что код актуален). Как-то так мыслю…
-3
import
и так работает, правда приходится компилировать. но кто не компилирует в наш век ?)
-1
Я не компилирую. Считаю, babel неизбежно ненужным. Сейчас Edge поддерживает даже классы. Предпочитаю современный код в ущерб совместимости в угоду динозаврам.
0
Вместо babel можно попробовать typescript — там можно использовать вообще все что-угодно (async/await, import, etc) + указывать таргет — все транспилируется куда надо, включая es5. Ну и получаем бонус в виде статической проверки типов.
-1
Не стандарт.
0
Стандарт не стандарт, а под ноду гораздо приятнее писать со статической типизацией, последними фичами языка и без необходимости установки монстроидального бабеля с разными плагинами — все идет одним пакетом. Как вариант — flowtype, но оно очень плохо развивается по сравнению с ts.
-1
Возможно. Но почему до сих пор нет хотя бы драфта? Я согласен с вами: есть сигареты, а есть сигары; что-то модно, а что-то вечно. Да и вечного тоже не бывает по сути. Просто внутреннее отторжение.
0
Насчет типизации. Я как-то так сделал и мне, в принципе, этого хватает.
// strip string to number
stripNum: (v) => +v.replace(/\D+/g,"") - 0,
// is HTML Object defined and how
htmlObj: (e) => RR.isO(e) ? e : RR.get(e),
// is callback defined
isC: (c) => c && RR.isF(c) ? true : null,
// is object
isO: (v) => typeof(v) === 'object' ? true : null,
// is string
isS: (v) => typeof(v) === 'string' ? true : null,
// is array
isA: (v) => typeof(v) === 'array' ? true : null,
// is function
isF: (v) => typeof(v) === 'function' ? true : null,
// is undefined
isU: (v) => typeof(v) === 'undefined' ? true : null,
// is number
isN: (v) => typeof(v) === 'number' ? true : null,
0
Фишка типизации не в этом, а в статической проверке типов в момент написания кода — в конечном JS никаких проверок не будет (что дает бонусы в виде повышения быстродействия и уменьшения размера кода). Валидацию внешних данных, разумеется, никто не отменял — JS остается JS-ом. Но после валидации — все внутренние постоянные проверки просто не нужны.
0
Господи…
Написать тысячу раз number, чтобы потом не ошибиться… Ожидал большего. У меня и так не возникает проблем, но за предложение спасибо.
Написать тысячу раз number, чтобы потом не ошибиться… Ожидал большего. У меня и так не возникает проблем, но за предложение спасибо.
-1
Если модуль написан изначально на ts, то вся эта портянка типов генерируется автоматически (одним флажком в tsconfig), причем может быть частью npm модуля (код на js + тайпинги — современные IDE подхватывают такое на ура), что уже используется свежими версиями пакетов. Если это legacy-проект, то да, руками, что есть боль и страдание.
-1
Пока не работаю на node. Нет серверного компилятора и кэша. Клиент от этого будет быстрее? :)
> Если это legacy-проект, то да, руками, что есть боль и страдание.
Я вас понял. Для меня это удовольствие. Но я и legacy не поддерживаю больше.
> Если это legacy-проект, то да, руками, что есть боль и страдание.
Я вас понял. Для меня это удовольствие. Но я и legacy не поддерживаю больше.
0
Статическая типизация дает уверенность в том, что все типы передаются внутри приложения правильно — это убирает необходимость их валидировать на типы вообще, отсюда потенциальное ускорение. Все данные, которые приезжают извне и неизвестны на момент транспиляции типизированного кода в чистый JS — их нужно валидировать очень подробно, после этого данные становятся «чистыми» для всего внутреннего кода и их не нужно валидировать на каждый чих. Если единственный смысл приложения в постоянном получении данных, их проверке и минимальной обработке, то плюсов от типизации немного, проще будет ее отключить (но останутся плюсы по сигнатурам методов — этакая замена JSDoc).
-1
Да, клиент определенно будет работать быстрее. За счет того что из кода пропадут перечисленные вами выше проверки из-за своей бессмысленности.
0
Меня часто ругают за то, что я экономлю на килобайтах трафика. Можно я вас поругаю за миллисекунды выполнения? Что typeof это настолько ресурсоемкая операция, что стоит об этом париться? (:
Это в любом случае где-то выполняется. Если нет проверки — значит есть какое-то приведение в уже скомпилированном виде. Или я ошибаюсь?
Это в любом случае где-то выполняется. Если нет проверки — значит есть какое-то приведение в уже скомпилированном виде. Или я ошибаюсь?
0
Нет никакого приведения и проверок — просто чистый «опасный» JS код. Все проверки делаются в момент транспиляции из ts в чистый JS: если типы не совпадут или могут быть проблемы с неоднозначностью проверки на null, например — оно заорет благим матом и откажется генерировать конечный JS код. Т.е или пишем правильно или не получаем JS код.
+1
Внезапно родилось хокку:
Весною набухают почки и на своем стоят типочки…
Спасибо за минусы :) Пропадает всякое желание посещать этот чудный ресурс: слишком «здраво» воспринимаете новичков.
Весною набухают почки и на своем стоят типочки…
Спасибо за минусы :) Пропадает всякое желание посещать этот чудный ресурс: слишком «здраво» воспринимаете новичков.
0
Про flowtype не согласен, он просто нацелен на типизацию, а не на компиляцию в JS
0
Говорим Flowtype — подразумеваем Babel, потому что без отрезания типов код не станет валидным JS. Т.е что так что так — транспиляция нужна, а зачем держать 2 инструмента, если можно все делать одним? Настраивать меньше, размером оно тоже выигрывает.
0
Flow очень правильная штука с очень грустным туллингом и процессом разработки. Настолько грустным, что тайпскрипт, похоже, победил. А жаль.
0
Это Вы с корпоративным клиентом не работаете. Можете себе позволить такие понты.
-1
UFO just landed and posted this here
Привет из 2023. Мы все дописали, import уже можно использовать!
0
Moment.js
Я бы не стал на него ориентироваться сейчас, т.к. авторы создали другой проект, только на этот раз в его основе нативный Intl — moment.github.io/luxon
0
И всё-равно те же самые родовые травмы. Я бы рекомендовал всё же эту легковесную шуструю изоморфную библиотеку с отличной поддержкой тайпскрипта: habrahabr.ru/post/263041
-3
А можно подробнее про родовые травмы moment.js ?
0
Тогда уж date-fns.org вместо монстра moment.js. Да, не весь функционал, но для обычных манипуляций с датами хватит за глаза.
+1
1. Еще один аналог работы с CSV файлами node-csvtojson
2. Монады monet.js
3. Библиотека для проверки строк string-similarity
4. Библиотека для раскраски текста в терминале chalk
5. Библиотека для конвертирования объектов в вложенные объекты используя ключи dot-object
6. Библиотека для подгрузки environment файлов перед стартом скрипта env-cmd
7. Подборка маленьких скриптов для JavaScript (не совсем библиотека но тоже полезная вещь) 30-seconds-of-code
8. HTTP клиент для браузеров и Node.js axios
Возможно мое описание не достаточно точно поэтому советую читать описание в репозиториях.
P.S. А вообще советую искать на GitHub по тегам Node.js, JavaScript и т.д
2. Монады monet.js
3. Библиотека для проверки строк string-similarity
4. Библиотека для раскраски текста в терминале chalk
5. Библиотека для конвертирования объектов в вложенные объекты используя ключи dot-object
6. Библиотека для подгрузки environment файлов перед стартом скрипта env-cmd
7. Подборка маленьких скриптов для JavaScript (не совсем библиотека но тоже полезная вещь) 30-seconds-of-code
8. HTTP клиент для браузеров и Node.js axios
Возможно мое описание не достаточно точно поэтому советую читать описание в репозиториях.
P.S. А вообще советую искать на GitHub по тегам Node.js, JavaScript и т.д
0
Подумать только, до чего дошел прогресс. Все больше и больше различных средств становится. А минификация штука вообще полезная — трафик меньше будет.
0
Sign up to leave a comment.
20 модулей для Node.js, о которых полезно знать