Является ли аргумент числовым?

Подобная функция может пригодиться, если вам нужно проверить данные, полученные из ненадежного источника, например, после парсинга.
1. Отсекаем все типы, кроме строк.
2. Проверяем, является ли аргумент числовым значением с помощью !NaN.
3. Если пункт 2 прошел проверку, то пытаемся получить десятичное число с помощью parseFloat и проверяем полученное значение с помощью того же !NaN.

Учитывайте, что в качестве разделителя чисел валидна только точка ".".

Возможно, у вас появился вопрос: "Почему бы не использовать базовые функции вроде parseInt или Number?". Причина в том, что иногда, они могут вести себя не очевидно. Например, частично парсить parseInt('12px') -> 12, не учитывать дробную часть parseInt('0.5') -> 0 или даже преобразовывать пробелы Number(' ') -> 0

#js

React. Частые ошибки: Prop-drilling

Prop-drilling – это передача одного свойства на несколько уровней вниз. Сам React никак не ограничивает глубину передачи пропсов, однако, если слишком увлечься, то можно получить проблемы с производительностью и расширением кодовой базы.

React компоненты перерисовываются каждый раз при изменении пропсов (или, как минимум, пытаются это делать, если компонент мемоизирован). Так вот, если прокидывать проп на несколько уровней ниже, то промежуточные компоненты будут так же перерисовываться, тем самым, понижая производительность.

На помощь может прийти React Context или любой менеджер состояний (например, Redux или MobX). С их помощью можно избавить промежуточные компоненты от передачи пропсов, а так же вынести бизнес логику в отдельные сущности.

P.S. Дока Redux на русском и дока MobX на русском (немного устарела, но концепция сильно не изменилась)

#react

Удовлетворяет ли элемент массива условию?

В начале небольшое пояснение: метод some проверяет, удовлетворяет ли какой-либо элемент массива условию, заданному в передаваемой функции.

Часто вижу, что вместо some используют [].findIndex(() => ...) !== 0 или даже [].find(() => ...) !== undefined.
Все три метода, действительно, очень похожи, и вы можете использовать findIndex или find вместо some. Причина по которой стоит использовать some – удобочитаемость. Мы же все стремимся к читаемому коду, верно?

Кстати, если вы проверяете массив на наличие в нем undefined, то find – заведомо плохая идея, т.к. независимо от содержимого массива, конструкция вроде arr.find((el) => el === undefined) !== undefined всегда будет возвращать false, потому что невозможно отличить найденный элемент от undefined, который вернулся из-за того, что ни один элемент не удовлетворил условию.

#js

Ловите полезный кастомный хук, который поможет избавиться от бойлерплейта.

Немного пояснений как он работает:
1. Трюк с useRef и useEffect на 8-12 строках нужен для того, чтобы не обязывать всех пользователей оборачивать handler в useCallback. Если просто передавать handler в зависимости useEffect на 14-22 строках, то этот useEffect будет срабатывать каждый ререндер, что не есть хорошо для производительности.

2. isSupported на 15 строке помогает, когда третьим аргументом передается элемент или ref элемента, которые не всегда могут быть в DOM на момент срабатывания функции

P.S. Код хука скину в комменты

#react

История ES модулей

Один из подписчиков попросил рассказать подробнее про ES модули. Материала набралось на целую статью с примерами.

Я постарался кратко разобрать Модуль паттерн, CommonJs и EcmaScript Модули, плюсы и минусы каждого из подходов. Если остались вопросы или хотите предложить свои темы для постов – буду ждать вас в комментах.

👉👉👉 Читать статью 👈👈👈

#js

Пока готовил статью про ES модули, наткнулся на интересный пример c eval.

Как думаете, чему равны evalX и x?

P.S. Если вы используете eval в своем проекте, задумайтесь, а очевидно ли он работает и действительно ли он необходим?

P.P.S. Ответ с объяснением скинул в комменты.

#js

Зоопарк CSS технологий

Хотел в субботу сделать короткий пост-обзор по современным CSS подходам, с которыми мне довелось поработать. Нюансов оказалось так много, что пост превратился в статью, которую я дописал только вчера ночью😃

Цель этой статьи не рассказывать подробно о каждом подходе, а дать краткое описание и подсветить преимущества и недостатки. Если заинтересует какая-то конкретная технология - дайте знать, расскажу подробнее.

Полную статью можно найти здесь. Ниже выжимка.

Inline стили. Учитывая все минусы, я рекомендую использовать их в комбинации с любым другим подходом для вычисляемых значений, которые проблематично описать в css;

Обычный CSS. Без БЭМ или CSS модулей адекватно можно сверстать, разве что, лабу в универе или пример в codeopen;

SASS/SCSS. Аналогично пункту выше. Не рекомендую использовать без БЭМ или CSS модулей;

CSS/SCSS + БЭМ. Классика. То, с чем можно построить приложение маленьких и средних размеров. На любом стэке. В больших приложениях растет риск коллизий имен и их решение превращается в квест. Для проектов на React есть варианты получше;

CSS модули. Золотая середина для приложений на React. Настроить под них вебпак не составляет труда, а в CRA вообще работают из коробки. Можно строить приложения любых размеров, используя все прелести css, не ломать голову над именами классов и не бояться за глобальную область видимости;

CSS-in-JS. Не стоит использовать для сайтов, в которых важен SEO, по крайней мере, run-time решения. Для маленьких проектов слишком много лишнего придется тянуть в проект. Хорошо подходят для средних и больших проектов и команд. В моей практике и styled-components и linaria хорошо показали себя на больших проектах-микрофронтах с UI китом.

Tailwind. Может хорошо себя показать в проектах любого размера и назначения. Должен показывать хороший SEO результат. Tailwind подойдет, если вы: синхронизированы с дизайнерами, готовы отказаться от абстрактных классов и длинные имена классов вам не режут глаз. Если нет - выберете что-то другое.

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

#js #react #css