Комментарии 13
Например, сегодня я узнал, что нельзя просто так создать пригодный к использованию массив из поля ввода.
Array($("input").val()) //бесполезно
//надо так:
var paste = $("input").val();
if(!isNaN(paste)) {//parseInt неуместен
lst = Array(parseInt(paste)||1).fill("") //0 нельзя, а пустой массив не сработает в цикле
}
Или надо создать массив заданной длины?
Честно говоря, после прочтения вашего коммента, я перепроверил: а он точно 2020 года?
Стандарт де-факто он на "олдскульных" сайтах с рендерингом html на стороне сервера, а не в современных SPA приложениях, пускай и с серверным рендерингом )
Ну и, имхо, бОльшую часть своей популярности он получил за решение некоторых проблем кроссбраузерности и коллбэк-ада, которые уже решены или нативно, или решаются бабелем.
Что и всегда: знать язык и стандартную библиотеку, чтобы не удивляться.
А js уже не молод, чтобы называть стандартное поведение, описанное в спецификациях и документациях, факапами.
Что конкретно в вашей задаче вызвало удивление?
1. Метод получения числа из строки, parseInt() далеко не всегда работает корректно. Например, он посчитает числом нумерованный список, но почему-то это будет число 1, а не 2 и не 3, если список состоит из трех пунктов. Бред, поэтому мы вынуждены использовать для проверки менее очевидный метод, и если бы не сервисы вопрос-ответов, копание в руководстве заняло бы слишком много времени.
2. Ок, мы вроде поняли что в этот раз пришло число (!isNaN), но зачем-то все равно преобразуем его к числу.
3. Часть выражения ||1 показывает, что внутри себя этот язык не всегда гарантирует, что разные значения одного и того же типа данных могут вызвать, а могут и не вызвать ошибку. Да, мы миримся с делением на ноль, но такие сущности неправильно множить без необходимости, есть даже специальный принцип в программировании, запрещающий делать это в хорошей программе, увы, я его сейчас не вспомню.
4. fill("") — заполнение уже созданного(!) массива пустыми(!!) значениями. Без этого некоторые итераторы его проигнорируют. Без этого массив как бы есть, но его как бы и нет. Такое вот дамское кокетство.
parseInt и parseFloat нужны для преобразования всяких «14px» в число «14». Он просто идёт итеративно посимвольно и заканчивает работу на первом невалидном символе.
Ну и допом возможность выбора системы счисления.
Для каста валидной string в number есть Number() или унарный “+”. Работают идентично.
Для каста float to int есть методы в Math.
isNaN пытается скастовать в string через Number. И уже Number(“blabla”) возвращает NaN
Вот тут я не понял. Мне казалось, вам массив нужен с минимальной длиной в единицу. Скорее всего у вас isNaN что-то пропускает, типа пустой строки. А parseInt от неё возвращает NaN. А Number(“”)===0.
А вот тут сложнее. Массив заданной длины не является заполненным значениями.
Так же как и пропущенный элемент: [1,2,,4] и [1,2,undefined,4] ведут себя по-разному. И это описано в спецификации.
Если вы сделаете .fill(undefined), то он станет работать корректно.
И согласен, это не очень логично, на первый взгляд. Это поведение можно воспроизвести просто изменив свойство length у массива.
Не знаю, может здесь нюанс в обратной совместимости. Может суть стандартных итераторов в обходе заданных значений, а не по индексам.
Нужно разбираться.
Какая-то детская викторина на уровне "Читал до я доки на MDN и reactjs.org", ни одного действительно интересного и нетривиального вопроса
В React все является компонентом — это основные конструктивные блоки веба.
Хуки компонентами не являются. ReactDOM.render() компонентом не является и т. п.
Вопрос в том, является ли транспайлер компилятором.
Подмножество компиляторов
Викторина по JavaScript и React