Именованный и неименованный экспорт​

Начнем с того, что экспорт бывает разный — именованный и неименованный.

Именованный экспорт — это использование ключевого слова export перед каждой сущностью или при использовании «паттерна» export list, когда все экспортируемые сущности перечисляются в одном месте файла:

// именованный экспорт
export const a = 1

// export list
const c = 3
const d = 4
const f = 5

export {
 c,
 d,
 f
}

Стандартный же экспорт — это экспорт с использованием конструкции export default:

// стандартный экспорт
const b = 2
export default b

Помимо разницы оформления каждого из способов экспорта в коде, также отличается и их импорт. В случае с именованным экспортом у нас есть возможность импортировать каждую сущность из файла по его названию:

import { 
 Status, 
 getUser, 
 render as renderFunction
} from './file'

Стандартный импорт:

import React from 'react'

А также их комбинация:

import React, { useState, useMemo } from 'react'

Но что насчет проблематики? Почему разработчики каждый раз сталкиваются с вопросом какой лучше экспорт выбрать?

Чтобы понять это, рассмотрим следующий пример:

import Angular from 'react' // абсолютно валидно

import { Status as UserStatus } from './file'

В двух импортах выше видна основная проблема — неявные переименования. Такие переименования сущностей могут путать разработчиков, никак не защищают от опечаток, что в совокупности приводит к неоднозначности именований. Из-за всех этих проблем export default является инструментом, использование которого только усложнит поиск чего-либо по коду и его отладку.

Также к минусам export default можно отнести то, что такие сущности индексируются статическими анализаторами медленнее и сложнее, что в больших проектах может повлечь за собой проблемы с линтингом.

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

Мой вывод: я стараюсь сократить использование export default до минимума, предпочитая именованный экспорт и импорт. Использовать export default валидно только для интеграции вашего кода с уже готовыми решениями, например, это может быть React.lazy и React.memo, которые работают только с export default по умолчанию. У меня есть удобный хак как это обойти, но это тема для отдельного поста.

Спасибо за прочтение, это важно для меня ❤️

#web #javascript #react #patterns

CSS можно в JS и это не всегда хорошо​

Фронтендеры как будто не могут договориться как им хочется писать стили 🙂. Вариантов очень много, разнообразных препроцессоров и инструментов в виде библиотек стилей, CSS фреймворков…

Вообще, CSS-in-JS — это некоторый подход, в котором мы отказываемся от массового использования стандартных CSS файлов и пишем стили внутри JS. Для реализации этого концепта есть несчётное количество библиотек, но для React основной я бы назвал styled-components. Лично я вижу повальное число проектов, в которых используется эта библиотека, да и сам использовал её в достаточно часто.

Причина проста: это очень удобно, по нескольким причинам.
1. CSS-in-JS позволяет генерировать стили динамически для одного класса. Стандартный CSS так не может, мы должны изменять стили только добавлением дополнительного класса, модификатора и т.д.
2. Дополнительная мета-информация при разработке переезжает из className в название самого тега. Если мы хотим как-то влиять на внешний вид нашего приложения, то классы мы будем записывать в переменные, соответственно прочитать их быстро не получится. В общем, сложно. Стилизованные компоненты же несут информацию о том, зачем они нужны, сразу из названия, и этой информации куда больше, чем просто div, aside, ul...
3. Упрощённая файловая структура. Формочки можно клепать ещё проще и быстрее, не переключаясь между файлами.

Возможно и звучит круто, но за всё это приходится платить достаточно высокую цену:
1. Стили создаются в рантайме и блокируют выполнение остального JavaScript на странице. Это приводит к проблемам с производительность, особенно для перегруженных систем. Всё это удобство в разработке приведет к тому, что пользователь будет плеваться от того, какое медленное приложение вы сделали.

Использование нативного CSS для браузера куда понятнее и быстрее, JS бандл становится меньше и грузится также быстрее, а стили подгружаются параллельно вашему коду.

В результате-то что? На мой вкус, CSS-in-JS — это и правда очень удобно. Но я полностью отказался от этого подхода в своих проектах, потому что не готов платить производительностью за все плюсы, что описал выше.

Если вы хотите писать стили быстро и качественно, то я действительно рекомендую обратить большее внимание на обычные модульные стили на каком-то препроцессоре или же вообще на Tailwind CSS. От последнего я, кстати, невероятно долго плевался, ну а потом как обычно: отрицание, гнев, торг, депрессия, влюбился… Точно рекомендую посмотреть, если ещё не пробовали)

Спасибо за прочтение, это важно для меня ❤️

#javascript #web #react #theory