Кодовая база

Неоплачиваемые стажировки: за/против Мало какая тема в айти комьюнити вызывает столько бурления, как неоплачиваемые стажировки. Одна часть комьюнити гневно порицает тех, кто осмелился опубликовать вакансию с бесплатной стажировкой на своем проекте, другая часть считает, что это хороший шанс для новичков влиться в профессию. Давайте разберемся, как обстоят дела на самом деле. Прежде всего нужно понять: проект проекту рознь. Это - самый главный фактор, который определяет, есть ли смысл вписываться в какой-либо проект на волонтерских началах. Для того, чтобы вы могли прокачать свои навыки на проекте, на этом проекте вы должны получать обратную связь от опытного разработчика, который подсветит вам ваши пробелы и ошибки. Например, блоггер S0ER периодически набирает ребят в проект Naris. Я сама участвовала в этом проекте, будучи уже далеко не джуном, и подчерпнула для себя много интересных разработческих фишек. Также многие крупные компании - например, Газпромбанк, Озон, ЦФТ, KTS - периодически набирают учеников на бесплатные курсы, в рамках которого вы также будете делать какой-либо учебный проект и получать обратную связь от менторов. Прокачка скиллов на таких проектах позволит вам не просто писать работоспособный код, но и сделать его гибким, поддерживаемым и масштабируемым. Однако сейчас на рынке появилось много предложений бесплатных стажировок от мелких работодателей. Часто в таких вакансиях обещают нанять вас в штат после бесплатной стажировки. За редким исключением, такие проекты не способны вас ничему научить, потому что у них нет такой цели, на них не применяются best practices, часто формальное ревью. По сути, это просто бесплатная работа. Я советую вам избегать таких проектов и не надеяться, что после бесплатной стажировки вас обязательно возьмут в штат, потому что у работодателя есть прекрасная возможность этого не делать. На таком проекте вы просто потеряете время и мало чему научитесь. Короче говоря: не стоит вестись на обещания «устроить в штат после бесплатной стажировки». Соглашайтесь только на те проекты, которые выгодны прямо здесь и сейчас. Выгода в бесплатных проектах заключается в возможности прокачать свои навыки и получить обратную связь от опытных коллег. Если проект не предлагает вам ни прокачки скиллов, ни денег, то не стоит тратить на него ни минуты своего времени.

Как в next.js на серверной стороне определить, десктопную или мобильную версию сайта рисовать? В популярных библиотеках для React существует много хуков, которые позволяют определить версию лейаута - мобильную или десктопную. Однако они все работают на браузерной стороне, а в next.js может потребоваться определить лейаут на серверной стороне, чтобы сразу отдать десктопную или мобильную верстку. Универсального рецепта у меня нет, но есть достаточно хороший: 1. Нам нужно получить заголовок user agent. В next это делается при помощи функции headers.

import { headers } from 'next/headers';

export default async function Page() {
  const userAgent = await headers().get('user-agent'));
   ….
}

2. В мобильных браузерах обычно есть слова Mobile, Android, iPhone, iPad. Решение заключается в том, чтобы найти, есть ли какое-нибудь из этих слов и полученном user agent. Например, если в девтулах поставить мобильную версию и iphone 14, то вернет Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.. Здесь есть сразу и Mobile, и iPhone.

Вот такой вот сайт я сделала себе за день при помощи нейросети https://v0.dev/, при этом бОльшую часть времени работы я потратила на тексты и на настройку хостинга. Закинула пропмтом тему сайта и понравившуюся мне цветовую схему, и сервис сгенерировал мне готовый проект на next.js. Мне осталось только скачать его, заменить тексты на свои и захостить :) Потыкать можно здесь: https://devmargooo.ru/

В одном из чатиков обещала рассказать, как я готовлю условные типы в typescript. Чаще всего они мне пригождаются, когда нужно один тип преобразовать в другой. Например, один раз мне нужно было написать функцию, которая получала объект с полями формы (имя, фамилия, город, возраст…) и вырезала оттуда все пустые строки. Таким образом, нужно было вывести тип-дженерик, который принимал бы исходный тип T и получал бы из него такой же тип, только с пустыми строками. Например, тип type User = { name: string; age: number; sex: Sex } нужно было преобразовать в { name?: string; age: number; sex: Sex }. Вот так вот я написала этот дженерик при помощи условных типов:

export type OptionalString<T extends Record<string, any>> = {
    [K in keyof T]: T[K] extends string ? string | undefined : T[K];
}

Дженерик проходится по всем полям в типе и проверяет, является ли это поле наследником от строки? Если да, то в новом типе это поле будет string | undefined, в противном случае - то же, что и было в исходном типе

На днях спросили, какие темы в Javascript нужно знать для стажировки по этому направлению. Приведу полный список здесь: - Переменные - let, const - Условия - if else - Циклы for, for of, for in, forEach, while - Функции - Типы данных (примитивы и объекты). Тип Symbol стажерам знать не обязательно :) - Методы строк, методы массивов, методы объектов - Промисы, async/await - Ключевое слово this, bind, call, apply - Таймеры: setTimeout, setInterval Это основы Javascript, которые необходимы стажеру для того, чтобы начать практиковаться. Все остальное можно выучить уже позже😊

Сегодня помогала фронтендеру в чате разобраться с проблемой. Собственно, проблема: в верстке футер не достает до правого края, хотя указана ширина 100%. Такие проблемы обычно возникают, когда какой-то потомок выпал из контейнера. Например, у потомка указана ширина 100% и у родительского контейнера есть паддинги, из-за паддингов суммарно ширина становится больше 100% и вот уже потомок выпал из контейнера. Рецепт дебага: 1. Нам нужно найти, какой элемент вывалился из контейнера. Идем в файл с html разметкой (или корневой компонент в вашем любимом фреймворке) 2. Комментируем ВСЕ. Проблема исчезнет, как и вся верстка с сайта. 3. Поочередно, по одной секции страницы, раскомментируем обратно 4. Та секция, на которой проблема снова появилась, и есть проблемная. В ней обычно легко найти вывалившийся элемент при помощи девтулзов браузера. Если нет, то рекурсивно повторяем историю с комментированием, но уже в рамках отдельной секции. P.S. Лендинг со скриншота я создала за пару минут в https://v0.dev. Спасибо Сергею и его каналу https://t.me/DragorWW_space за то, что регулярно освещает крутые нейронки для работы!

В чем основные преимущества серверных компонентов перед клиентскими в Next.js? Серверные компоненты рендерятся только на сервере. Браузер не получает js код серверных компонентов, а получает только json-подобное описание необходимомого virtual dom, называемое rsc payload. За счет этого бандл становится меньше. Второе серьезное преимущество - это поддержка streaming: сервер не дожидается, пока все дерево компонентов будет готово, а отправляет rsc payload по мере готовности, чтобы браузер мог отобразить то, что возможно, как можно скорее. На месте неготовых компонентов будут плейсхолдеры, и браузер заменит их на компоненты сразу, как получит их rsc payload с сервера.

Возможно, я кого-то удивлю, но "клиентские компоненты" в next.js рендерятся на... сервере. А затем гидратируются на клиенте, и поэтому код таких компонентов прилетает в браузер. В отличие от них, серверные компоненты не гидратируются на клиенте, а рендерятся только на сервере.

Вчера побывала на ежегодной конференции от Яндекса «Я 💛 Фронтенд» и наконец-то смогла победить в соревновании по верстке вслепую Code in the dark! До этого два года подряд у меня было второе место :) Дали красненькую Яндекс станцию

Небольшой лайфхак. Допустим, у вас есть проект и есть библиотека компонентов, которую вы используете в проекте. Вы делаете новый компонент в библиотеке. Для того, чтобы проверить, как он интегрируется с проектом, не обязательно релизить новую версию библиотеки - достаточно просто сбилдить библиотеку и подменить сборку библиотеки в node modules вашего проекта на только что собранную вами. Если ваш проект на next.js, то необходимо еще и удалить собранный next-ом билд проекта и пересобрать заново через next dev.

Последний пост в этом канале был несколько месяцев назад, и я поняла, что хочу оживить его. За это время я успела сменить команду и получить много разного интересного опыта, которым буду делиться с вами 🥰 Сегодня хочу коснуться такой темы, как стейт менеджеры. Я с огромным удовольствием посмотрела доклад Дмитрия Бабина “Вам не нужен state менеджер “. Дмитрий сделал действительно классный анализ существующих на данный момент стейт менеджеров (упустив, однако, effector и mobx), а также сравнил их с хранением состояния средствами react. Вставлю свои пять копеек. Дмитрий подчеркивает такую проблему стейт менеджеров, как отсутствие экосистемы (на reatom нет библиотеки работы с формой и тд), объясняя это тем, что если мы заносим в проект стейт менеджер, то мы хотим писать на нем всю бизнес логику. Я всегда относилась к стейт менеджерам иначе - в первую очередь я использовала их для хранения данных, используемых глобально (как минимум в нескольких местах приложения), а не как место для написания бизнес логики. Мои требования к стейт менеджеру следующие: - Стейт является структурой вида “ключ-значение”. - Содержит геттер данных по ключу. - Содержит сеттер данных, причем для каждого поля может быть только один сеттер. Этому требованию очень удобно удовлетворяет Redux: в нем принято писать один action creator, который возвращает action, и диспатчить этот action creator из разных мест приложения; но не удовлетворяет, например, effector, потому что он допускает установку данных как в push дизайне (вызов ивента), так и в pull дизайне (подписка стора на эффект). Почему это так важно, опишу позже. - Удобные девтулзы. Бизнес логику я распределяла и хранила в: 1. компонентах реакт (например, вызов запроса, если он вызывается только в одном месте), 2. в ts классах (отлично подходит для кода, не требующего механизмов реактивности), 3. в redux-thunk (в небольших приложениях) или 4. в эпиках rxjs (в больших приложениях). Таким образом, я изначально проектировала свой код так, чтобы стейт менеджеру отводилась роль хранилища, поэтому с проблемой, о которой говорит Дима, я за свой профессиональный опыт так и не столкнулась. Для чего я вообще использую стейт менеджеры? Главная проблема, которую они для меня решают, возникает вовсе не в процессе написания кода, а в процессе поддержки и эксплуатации. Хранение глобальных данных во время написания кода - это вообще не проблема. Я могу легко написать код, который хранит данные где угодно - в реакт хуках, в контексте, да хоть в объекте window. Однако потом наше приложение постепенно обрастает пользователями и фичами, и рано или поздно мы неизбежно сталкиваемся с багом: в наших глобальных данных почему-то лежит не то, что мы ожидаем. Ждем foo, а лежит bar. И дальше наша - понять, почему так получилось, и устранить проблему. Для этого, во-первых, надо понять, какие данные записаны неверно. И вот тут-то пригождаются топовые девтулзы редакса: я просто открываю девтулзы и смотрю текущий слепок данных, в котором достаточно легко нахожу неверные данные. Дальше надо понять, откуда записались неверные данные. Для этого я ставлю в соответствующем action creator брейкпойнт дебаггера и в два счета нахожу в колстеке виновника. Таким образом, два последних пункта, про которые я пишу - удобные девтулзы и один сеттер данных, в который можно поставить дебаггер - для меня принципиальны. Поэтому я уже много лет остаюсь верной редаксу: мне не нужны суперфичи в стейт менеджере, мне нужны удобные девтулзы для поддержки и дебага приложения. Ни один другой стейт менеджер, ровно как и нативные фичи реакта (контекст, хуки) такой удобный дебаг для меня не предоставляют.

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

const [error, setError] = useState<string | undefined>(); // в форме есть ошибки
const [loading, setLoading] = useState<boolean>(false); // форма загружается на сервер
const [isSuccessful, setIsSuccessful] = useState<boolean>(false); // форма успешно отправлена

Здесь разработчик создает целых три разных независимых состояний в коде (состояние ошибки, состояние загрузки, состояние успеха), но логически весь этот код отвечает за состояние формы - то есть за одно и то же состояние. Это одна форма, которая может либо находиться в одном из четырех состояний: 1. в состоянии загрузки 2. в состоянии ошибки 3. в состоянии успеха 4. в состоянии готовности к редактированию. Несложно посчитать, что код выше сгенерирует нам целых восемь различных состояний вместо четырех необходимых. Помимо запутанности и сложночитаемости, такой код плох тем, что мы генерируем недостижимые состояния, которые непонятно, как обрабатывать. Например, что делать, если у нас одновременно есть ошибка и переменная isSuccessful равна true? Скорее всего, программист выберет какое-то одно состояние как приоритетное, но так или иначе, такой код будет порождать запутанность и баги. Выход из этой ситуации - это использование конечных автоматов. Конечный автомат - это математическая модель, описывающая конечный набор возможных состояний и определяющая, что автомат может находится только в одном из этих состояний в конкретный момент времени. Также автомат может переходить из одного состояния в другое. В коде на React конечный автомат можно довольно создать, используя редюсер, а возможные состояния удобно описываются через тип-сумму:

type FormState = {
    state: 'loading';
} | {
    state: 'error';
    message: string;
} | {
    state: 'ready';
} | {
    state: 'successful';
}

type FormAction = {
    type: 'set_loading'
} | {
    type: 'set_error',
    payload: {
        error_message: string;
    }
} | {
    type: 'set_ready',
} | {
    type: 'set_successful'
}

const initialState: FormState = { state: 'ready' };

const formReducer = (state: FormState, action: FormAction):FormState => {
     // ...
}

Созданные formReducer и initialState мы можем использовать в нашем компоненте через useReducer. Таким образом, мы получили удобное декларативное описание возможных состояний нашей системы, а также совокупность переходов из одного состояния в другое.

Брендированные типы в typescript Привет, с вами снова @devmargooo и сегодня мы с вами поговорим о типизации в приложении на typescript. Структурная типизация в typescript, в отличие от номинативной, определяет совместимость типов, основываясь не на названии типа, а на его наборе полей. В этом структурная типизация похожа на утиную: если это выглядит как утка, плавает как утка и крякает как утка, то, вероятно, это утка. К сожалению, это может приводить к проблемам. Следующий код не приведет к ошибке компиляции, несмотря на то, что тип some_string указан как string, а не Email :

type Email = string;

function auth(login:Email) {}

const some_string:string = "some_string";

auth(some_string); // ok

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

type Email = string & { _: 'Email' };

Теперь тип Email будет структурно не совместим с типом string. Мы получим ошибку компиляции:

type Email = string & { _: 'Email' };

function auth(login:Email) {}

const some_string:string = "some_string";

auth(some_string); // Argument of type 'string' is not assignable to parameter of type 'Email'.

Чтобы код заработал, нам придется явно указывать, что переменная имеет тип Email:

const some_string = "some_string" as Email;

Или добавить проверку в наш код, которая также будет выводить нужный нам тип:

function isEmail(value:string): value is Email {
    const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
    return emailRegex.test(value);
}

Для удобства создания брендированных типов можно воспользоваться дежнериком:

type Brand<B extends string, T> = T & { readonly _: B }

Пример использования:

type Email = Brand<'Email', string>;