Что такое SSL и TLS​

Не так давно я разбирал разницу между HTTP и HTTPS и в этом посте были затронуты SSL и TLS, но я так и не раскрыл до конца что это такое. Исправляюсь.

SSL и TLS — это протоколы шифрования данных транспортного уровня по модели OSI. Оба этих протокола выполняют одну и ту же функцию — обеспечение безопасности передачи данных между клиентом и сервером в сети.

Безопасность обеспечивается путём обмена ключами шифрования между клиентом и сервером. Клиент всегда первым инициализирует процесс обмена ключами, запрашивая сертификат сервера.

Сертификат — это набор информации о сервере, а именно:
— домен
— публичный ключ сервера
— серийный номер сертификата
— название организации, которая выдала сертификат
— цифровая подпись

Клиент получает сертификат сервера и генерирует свой случайный ключ шифрования и отправляет его обратно также в зашифрованном виде.

публичный ключ сервера + сегенерированный ключ = ключ, отправляемый обратно

Таким образом, клиент и сервер обмениваются ключами и и устанавливают защищённое соединение между друг другом.

Весь этот процесс имеет специальное название — «рукопожатие», или же «handshake».

SSL и TLS используются до сих пор. По сути, SSL — это более простая и старая технология, которую рекомендуется заменять на TLS во всех возможных случаях. Но, не смотря на все рекомендации, все ещё достаточно много проектов используют SSL.

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

#web #theory

TypeScript или JavaScript: что приоритетнее?​

Есть много адептов и хейтеров TypeScript, в этом вопросе всё не так однозначно, просто выскажу своё мнение.

Я тащу TypeScript в любой проект, где у меня есть такая возможность, и категорически против использования чистого JavaScript без типов. Однако, есть случаи, где это просто необходимо, и использование TS только усложняет вашу жизнь.

Для меня TypeScript решает множество проблем, я его невероятно люблю и стараюсь погружаться в него всё глубже, а всё потому что разработка с ним для меня становится в разы более приятным занятием, чем без него. Код на TypeScript более читаемый, в него можно быстрее погрузиться и внести изменения, а приложения, написанные на нём, потенциально ловят гораздо меньше багов.

Также очень нравятся дополнительные типизируемые сущности в языке в лице типов и интерфейсов. Они позволяют понять что делает тот или иной код, порой, даже без чтения самого кода. Мы можем взглянуть на интерфейсы ввода/вывода данных и примерно понять что происходит в конкретной функции, что упростит её чтение и понимание в дальнейшем, если остается такая необходимость. То есть типы, помимо очевидной пользы в плане стабильности кода, несут и дополнительную функцию — документация кода.

Но у TypeScript есть и недостатки. Для меня главным недостатком является то, что компилятор TypeScript может быть неоптимален. Команда разработчиков старается быстро править все нюансы, но пару раз точно я ловил кейсы, где проблема производительности решалась изменением расширения файла на .js, а значит, что никто не защищен от подобных казусов.

Мой вывод заключается в том, что если TypeScript и ужасен, как об этом некоторые говорят, то чистый JavaScript для меня ещё страшнее. Я себя, по крайней мере на данный момент, больше отношу к адептам TS, нежели к его противникам.

Если говорить с точки зрения рынка, то современную фронтенд разработку без TypeScript мне представить не получается. За последние годы, навык разработчиков «Знание TypeScript» перешёл из категории «Желательно» в категорию «Обязательно» и очень плотно там закрепился. Прогнозов на обратный процесс пока точно не будет. Есть ощущение, что TypeScript с нами на очень долго.

Поэтому если вы хотите быть максимально конкурентноспособным на рынке, то стоит признать, что TypeScript — стандарт. Если вы начинающий разработчик, то придётся смириться с тем, что TypeScript придётся выучить.

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

#web #typescript #javascript

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

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

Именованный экспорт — это использование ключевого слова 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

Обратная связь

Друзья, я ещё раз хочу напомнить, что вы можете поделиться своими идеями для постов. Моя личка открыта и я рад пообщаться с каждым.

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

У меня нет цели что-либо навязать или продать, я готов рассмотреть любое ваше обращение полностью бесплатно. Не стоит думать, что это какая-то гениальная замануха на деньги — это не так)

Спасибо за ваш интерес к проекту. Будем на связи!

Личка — @denisputnov

JSON Web Token​

Методов авторизации и аутентификации есть много, но в последнее время большинство из них основывается на JWT.

JSON Web Token — это созданная в определенном формате base64 строка. JWT считается одним из самых безопасных и удобных форматов для передачи токенов и небольшого набора пользовательских данных с запросом.

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

Каждый токен доступа состоит из трёх основных частей:

— Заголовок, в котором определяется информация о самом токене

— Полезная нагрузка — JSON объект, куда записываются все данные, необходимые для авторизации

— Подпись — ключ, который, пусть и не позволит зашифровать сам токен, зато дает возможность валидировать токен на изменения.

Части токена разделяются точками.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJwcm9nd2F5IiwiaWF0IjoxNjg4MDMzMzI1LCJleHAiOjE3MTk1NjkzMjUsImF1ZCI6Ind3dy5wcm9nd2F5LmNvbSIsInN1YiI6InByb2d3YXkiLCJuYW1lIjoiRGVuaXMiLCJzdXJuYW1lIjoiUHV0bm92IiwiZW1haWwiOiJwcm9nd2F5QGVtYWlsLmNvbSIsInJvbGUiOiJBRE1JTiJ9.BTdcnNwZBfAHEmZEwf2P7s724Q1sZ60N2dHVRXhGtHI

Вот так это может выглядеть.

В этом токене в качестве полезной нагрузки использовался такой объект:

{
 "name": "Denis",
 "surname": "Putnov",
 "email": "progway@email.com",
 "role": "ADMIN"
}

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

Да и вообще, чем меньше данных о пользователе, тем лучше.

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

#data #theory #useful

Делегирование событий​

Делегирование событий — это один из базовых способов оптимизации работы с событиями. Суть заключается в том, что используя особенности событийной модели DOM, а именно, — всплытие, у нас появляется возможно зарегистрировать всего один обработчик вместо нескольких. Хороший пример — обычный туду лист.

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

При использовании делегирования мы сможем использовать лишь один статичный слушатель:

<ul>
  <li>Купить молоко</li>
  <li>Сходить в спортзал</li>
  <li>Закончить отчет</li>
  <li>Починить кран</li>
  <li>Позвонить другу</li>
</ul>

И вот же пример кода с обработкой таких событий:

const todoList = document.querySelector('ul');

function handleTodoClick(event) {
  const target = event.target;
  if (target.tagName === 'li') {
    target.classList.toggle('done');
  }
}

todoList.addEventListener('click', handleTodoClick);

Этот код добавляет слушатель событий к родительскому элементу списка ul вместо каждого отдельного элемента списка li. Когда пользователь кликает на элемент списка, событие всплывает от li до ul. Без использования делегирования, нам пришлось бы вешать всё новые и новые обработчики событий для каждого элемента списка.

Конечно же, этот паттерн доступен не только в разработке на нативном JavaScript, но и поддержан во всех современных UI фреймворках. По крайней мере, среди тех, что знаю я.

Делегирование спасёт вас от большого веса приложения в оперативке, т.к. каждый слушатель занимает какое-то пространство в WebAPI, ускорит процесс отрисовки и позволит гораздо быстрее и проще вносить изменения в код вашего приложения.

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

#javascript #web #useful

Как остановить выполнение интервала​

Я думаю, что большинство уже знают что такое setInterval. Если же вдруг нет, то:

setInterval — глобальная функция JavaScript, которая позволяет запускать какой-либо код раз в некоторое время. Например, каждые 300 миллисекунд.

Выглядит это следующим образом:

setInterval(() => {
 console.log('Привет, мир!')
}, 300)

Этот console.log будет выполняться бесконечно каждые 300 миллисекунд. Но что же делать в том случае, когда подобное цикличное выполнение нужно остановить? Этот вопрос может поставить кандидата в неудобную ситуацию, хотя, на самом деле — всё просто.

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

const interval = setInterval(() => {
 console.log('Привет, мир!')
}, 300)

clearInterval(interval)

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

#javascript #theory #web

Синтаксис async/await

В продолжение к посту о Promise, крайне актуально разобрать ещё один метод работы с асинхронным кодом, а именно — синтаксис async/await.

Ничего страшного и сложного, это такой же способ обработки асинхронных операций, только синтаксически он выглядит иначе.

По сути, async/await — это синтаксический сахар над промисами, который позволяет делать код более читаемым. Этот синтаксис не приносит ничего нового, а лишь упрощает работу с промисами.

Для того, чтобы разобраться, предлагаю пример запроса на сервер:

const data = fetch(`https:/some.api.com/users`)
 .then(response => {
  return response.json()
 })
 .then(users => {
  return users.map(...)
 })

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

const getData = async () => {
 const response = await fetch('...')
 const users = await response.json()
 return users.map(...)
}

const data = getData()

Есть определённое ощущение, что код менее перегружен и выглядит проще, не так ли?

Причём важно помнить, что можно использовать обычные методы then, catch и другие даже в синтаксисе async/await, то есть следующий код абсолютно валидный:

const getData = async () => {
  // можем вызвать then у fetch, т.к.
  // fetch - это тоже промис
 const users = await fetch('...').then(res => res.json())
 return users.map(...)
}

const data = getData()

Крайне советую использовать обновлённый синтаксис, поскольку такой код проще рефакторить и читать, но и не забывайте о обычных промисах. Ну пожалуйста 🥲

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

#web #theory #javascript

Что такое Promise?​

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

Также отдельно стоит отметить, что промис является микрозадачей.

У Promise есть несколько состояний:
— pending — ожидание — такое состояние будет у промиса в момент его создания и до того момента, как асинхронная операции не будет выполнена. После выполнения асинхронной операции, Promise переходит следующие два состояния — fulfilled или rejected
— fulfilled — успех — операция выполнена успешно
— rejected — ошибка — если вдруг в цепочке промисов возникла ошибка

О какой цепочке речь? У Promise есть три метода, которые позволяют создавать из обычного промиса целую цепочку и обрабатывать данные последовательно.
— then — метод, который принимает результат предыдущего промиса и возвращает новый результат
— catch — метод, который позволяет обработать ошибку операции
— finally — то, что будет выполнено всегда после цепочки промисов, вне зависимости от того завершился он с успехом или нет

Типичный вид промиса следующий:

new Promise((resolve, reject) => ...)
 .then(...)
 .then(...)
 .catch(...)
 .finally(...)

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

const promise1 = new Promise((resolve, reject) => ...).then(...)

const promise2 = promise1.then(...)

promise2.catch(...).finally(...)

Также обратите внимание на то, что callback промиса принимает два аргумента — функции resolve и reject.

Они нужны для того, чтобы перевести Promise из состояния pending в два других, причем reject приведёт промис к состоянию rejected и вызовет методы catch, если они есть в цепочке, а resolve либо переведёт нас к следующему в цепочки then с текущим статусом, либо переведёт Promise в состояние fulfilled.

На самом деле, рассказать в рамках поста эту тему подробно просто невозможно. Я бы не сказал, что эта тема сложная, она просто достаточно объёмная. Вдумчивое изучение позволит вам понять что такое Promise за пару часов.

Очень советую статью о промисах на Доке для самостоятельного изучения.

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

#javascript #web #theory

Что такое CORS​

CORS — Cross-Origin Resource Sharing — стандартный механизм регулирования доступов веб-страниц к ресурсам других доменов. Это политика доступа.

Браузер блокирует доступ к доменам, чтобы исключить некоторые уязвимости (например, чтобы ваши cookies не улетели к третьим лицам).

По умолчанию, с домена, скажем, first.com, мы не можем отправить запрос к домену second.com. Именно поэтому многие разработчики часто ловят ошибку типа XMLHttpRequest cannot load..., когда вы делаете запрос к стороннему API с приложения, развернутого на localhost.

Также можно сказать, что CORS — это некоторая система заголовков запроса. Подробно об этой политике можно прочитать в отличной статье MDN, а если вам интересно конкретно моё изложение, то его можно найти на сайте доки в одной из статей, что я писал 🙂

#web #theory

Всплытие и погружение событий — Событийная модель​

Всплытие и погружение событий являются механизмами обработки событий в DOM API.

Суть всплытия заключается в том, что когда на элементе происходит событие, обработчики сначала срабатывают на нём, потом на его родителе, затем выше и так далее, вверх по цепочке предков. Самым высоким предком в цепочке, корнем DOM дерева является тег <html>.

Погружение событий, наоборот, означает, что событие сначала обрабатывается на самом верхнем элементе в документе, затем на его дочерних элементах и так далее, до самого вложенного элемента, который в событийной модели называется event.target.

Событийная модель включает в себя следующие этапы:
1. Погружение — Capture — событие перехватывается на верхнем элементе и передается по цепочке родительских элементов вниз к самому вложенному элементу.
2. Цель — Target — событие достигает целевого элемента, на котором оно произошло.
3. Всплытие — Bubbling — событие всплывает от целевого элемента обратно по цепочке родительских элементов до самого верхнего элемента.

Механизм всплытия и погружения событий позволяет обрабатывать события на разных уровнях и в разной последовательности.

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

Об этих процессах прилагаю два отличных материала на русском языке:
1. Событийная модель — doka.guide
2. Всплытие и погружение — learn.javascript.ru

Оба материала более чем достойны вашего внимания. Пересказывать и без того отличные тексты в рамках телеграмм поста я просто не вижу смысла.

#web #javascript #theory

Книги — это не всегда круто​

Напоминаю, что в этом канале могут быть не только задротские разборы теории, а в том числе какие-то мысли из моей головы. Тут из разряда “накипело”

Книга, как и любой инструмент обучения, является лишь одной из форм представления информации. В моём понимании, прочтения достойны лишь те книги по программированию, которые дают:
1. Углубленное понимание
2. Понимание тенденций, истории развития, практик с опорой на исторические факты
3. Фундаментальные неустаревающие знания

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

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

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

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

Во всех остальных случаях, книги, на мой субъективный взгляд, противопоказаны. Гораздо выгоднее потратить время на получение информации из других источников. Вероятно, она будет более поверхностна, но зачастую этого уровня будет достаточно. А если речь идёт о динамично изменяющемся инструменте — это сюр и бесполезная трата денег. Чаще всего вашей лучшей книгой будет официальная документация инструмента на его же сайте.

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

Лично мне, как разработчику, было невероятно интересно читать лишь те книги, что к IT относятся лишь от части, например:

Scrum. Революционный метод управления проектами
Rework — о корпоративном развитии от создателей Ruby on Rails
Мифический человеко-месяц — о ведении проектов

Может я просто больше менеджер, чем разработчик? 🤔

#blog

Что такое MVP​

Я тут заметил, что позволяю себе использовать этот термин достаточно часто, но поста о том что это на самом деле такое у меня не было. Нужно исправлять.

MVP — Minimum Viable Product — минимально жизнеспособный продукт — это минимальный набор возможностей продукта, позволяющей ему выполнять свою изначальную задачу — так или иначе функционировать или же приносить хоть какие-то деньги.

MVP помогает команде разработчиков быстро и дешево проверить гипотезы о продукте, собрать обратную связь от пользователей и определить, какие функции и изменения нужно внести для улучшения продукта.

MVP калькулятора — сложение, вычитание, умножение и деление двух целых чисел. Возведение в степень, факториал, логарифмирование, построение графиков — дополнительный функционал, который, скорее всего, в MVP не входит.

MVP Telegram — список чатов. Стикеры, каналы, папки, архив чатов, менеджмент уведомлений, возможность установки своей темы — всё это дополнительный функционал, который в MVP не входит.

Важно чувствовать границу между «необходимым» и «возможным». Это важно.

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

#theory

Data-атрибуты​

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

<button data-order="1">Кнопка</button>

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

button[data-order] {
 order: attr(data-order)
}

Либо как-то обработать data-атрибут в JavaScript:

const element = document.querySelector(button[data-order])

const order = element.dataset.order

Стоит ли использовать data-атрибуты сегодня? Абсолютно точно да, но только в паре случаев: для более удобного тестирования и для чего-то, связанного с динамическим отображением. Для тестирования data-атрибуты могут быть использованы для однозначного поиска какого-либо элемента в вёрстке, например:

<button data-testid="1">Кнопка</button>

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

Да и в контексте современных web-фреймворков, использование data-атрибутов всё больше теряет смысл из-за того, что фреймворки предоставляют куда более удобные и безопасные способы хранения данных

#web #theory #javascript #useful

Различные способы загрузки скриптов​

Уже не просто классический, а, скорее, стереотипный вопрос с фронтенд собеседования — это разные способы подключения скриптов к странице.

Начать стоит с того, что каждый скрипт на странице подключается при помощи тега script:

<script src="index.js"></script>

Также стоит учитывать, что HTML разметка парсится сверху-вниз, а загрузка скрипта через тегscript является блокирующей операцией при загрузке вёрстки. Это значит, что браузер, доходя до тега script, полностью прекращает дальнейший парсинг и отрисовку HTML до того момента, пока скрипт не будет загружен и выполнен.

Чтобы решить эту проблему, есть ещё два варианта асинхронной загрузки скриптов.

<script async src="index.js"></script>
<script defer src="index.js"></script>

Оба варианта загрузки являются асинхронными и не блокируют отрисовку и парсинг HTML. Но в чём же тогда разница? В порядке выполнения.

Если на странице будет несколькоasync скриптов, то выполнятся они будут в порядке загрузки. То есть каждый скрипт будет выполнен ровно тогда, когда скачается, вне зависимости от того порядка, в котором скрипты подключаются в файле. Также async скрипты не подходят для загрузки скриптов, активно взаимодействующих с HTML разметкой, поскольку такой скрипт может быть загружен и выполнен ещё до того, как успеет построиться DOM дерево.

Скрипты defer также загружаются асинхронно, но, в отличии от async, сохраняют порядок выполнения. Более того, все defer скрипты дожидаются построения DOM дерева, даже если были загружены ранее, из-за чего взаимодействие с разметкой из таких скриптов немного удобнее и безопаснее.

И это, в целом, все отличия, которые стоит знать для ответа на этот вопрос.

#javascript #web #useful #theory

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

Какой цикл в JS самый быстрый

Из серии занятного. Наткнулся на занятную статью, где описывается какой цикл в JS самый быстрый. Если коротко, то обычный for.

Было уже много бенчмарков на тему того такой цикл быстрее чего-то вроде forEach или for..in и for..of , так что это мы возьмем за данное. А вот что действительно интересно, так это то, что стандартный вариант записи цикла for не является самым эффективным:

for (let i = 0; i < arr.length; i++) {
  // какой-то код
}

А всё почему? Потому что мы постоянно обращаемся к arr.length, что по своей сути — геттер, а геттеры всегда работают медленнее обычного обращения к переменной. Тогда можно прибегнуть к хаку, когда длина массива вычисляется заранее и присваивается к переменной лишь единожды:

const arrLength = arr.length;

for (let i = 0; i < arrLength ; i++) {
    // какой-то код
}

Но вот что автор не упоминает, так это то, что можно избежать такой записи и использовать просто обратный цикл:

for (let i = arr.length - 1; i >= 0 ; i--) {
    // какой-то код
}

Таким образом мы обратимся к длине массива только единожды и максимально выиграем время.

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

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

#theory #javascript

Что такое префиксные свойства и зачем они нужны?

Префиксные свойства — это особые свойства CSS, которые дублируют некоторые стандартные CSS свойства для обеспечения совместимости с различными браузерами.

Изначально префиксные свойства были придуманы для одной простой вещи — кроссбраузерной вёрстки. Но в последнее время идет активное обсуждение отказа от этого подхода и выравнивания названия свойств между браузерами, поэтому это уже не так актуально.

Что интереснее, префиксные свойства позволяют работать с экспериментальными фичами браузера, например изменять скроллбары:

/* ширина скроллбара */
::-webkit-scrollbar {
  width: 10px;
}

/* задний фон */
::-webkit-scrollbar-track {
  background: #f1f1f1;
}

/* ползунок */
::-webkit-scrollbar-thumb {
  background: #888;
}

/* ползунок при наведении */
::-webkit-scrollbar-thumb:hover {
  background: #555;
}

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

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

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

Пример с кастомными скроллбарами

#web #theory #web #design

Ссылочные типы и типы значений в JavaScript

Перед прочтением я рекомендую пробежаться по ещё одному посту из канала о том, какие типы данных есть в JavaScript.

В языке JavaScript, типы данных можно разделить на две большие группы:

Типы значений — примитивы — данные, что языком воспринимаются по конкретному значению. Например, строка "Hello, World!" или число 5.

Ссылочные типы — типы данных, которые интерпретатор языка воспринимает по ссылке. Переменная больше не хранит в себе конкретное значение, зато сохраняет ссылку на место в памяти, где это самое значение хранится.

К ссылочным типам данных относятся:
— объекты
— массивы
— функции

Казалось бы, а какая разница? Но разница заключается в способе хранения и передачи этих самых данных через переменные, а так же в способе взаимодействия с ними.

Типы значений потому и называются примитивами, так как максимально просты и предсказуемы в этом плане. Такие переменные, по сути, представляют собой просто некоторую последовательность байт. При сравнении таких переменных, всё, что нужно сделать языку — посимвольно сравнить цепочки байт и выдать результат.

Ссылочные же типы, в свою очередь, могут вызвать много проблем при работе с ними. Переменная сохраняет под собой не конкретную последовательность байт, а, как и говорилось выше, лишь некоторую ссылку на ячейку памяти, в которой нужная для нас информация (байты) и записаны. Из ключевых особенностей таких типов данных сразу же приходит на ум их копирование, с чем часто возникают проблемы у новичков и не только.

Например, в этом случае мы получаем не ожидаемый для многих вывод в консоль:

const obj = {
  name: "Denis",
  address: {
    street: 'Lenina',
    apartment: 10
  }
}

const clone = Object.assign({}, obj)

obj.address.street = 'Pushkina'

console.log(clone.address.street) // Pushkina

Связано это со спецификой работы Object.assign и особенностями копирования вложенных объектов. В этом случае копирование считается неглубоким, поэтому скопированный объект также изменяется.

Более подробно о понятии глубокого копирования я расскажу в отдельном посте. Он будет одним из следующих.

#javascript #data #theory #useful