Forwarded from S0ER
Promise.race
Всем привет, на связи Марго @devmargooo и сегодня я расскажу вам про Promise.race.🏎 Promise.race принимает в качестве аргумента массив промисов и возвращает результат того промиса, который завершится первым. Значит ли это, что после завершения Promise.race можно просто забыть про те промисы, которые проиграли гонку? Оказывается, нет. В 2017 году была описана интересная утечка памяти в Promise.race https://github.com/nodejs/node/issues/17469#issuecomment-685216777. Эта утечка интересна не сама по себе (мне кажется, Promise.race не так часто используют), а тем, что она представляет собой очень показательный пример утечки памяти в js через замыкания. Рассмотрим следующие тезисы.
1. Промис сохраняет свой результат все время, которое он живет.
Некоторые разработчики считают, что если мы не используем результат, который вернул промис, то он освободит память сразу после того, как промис завершится. Это не так! Результат промиса сохраняется в его внутреннем свойстве result все время, пока живет (= ссылочно доступен) сам промис.
2. Также, если промис зарезолвился, это еще не значит, что данные внутри его функции-исполнителя (функция, которую передали в конструктор промиса) больше не удерживаются в памяти. Нет, они могут удерживаться в памяти, например, если внутри исполнителя был setTimeout.
3. Рассмотрим следующий код и попробуем память, когда из памяти будет удален “super string”.
В данном случае neverResolve завис в памяти, а с ним и весь родительский промис p. Результат промиса resolveString сохранился как внутренее свойство result объекта p. Если “super string” - это тяжелые данные, то мы получим существенную утечку памяти. По всей видимости, механизм утечки памяти в Promise.race аналогичен вышеизложенному.
Всем привет, на связи Марго @devmargooo и сегодня я расскажу вам про Promise.race.🏎 Promise.race принимает в качестве аргумента массив промисов и возвращает результат того промиса, который завершится первым. Значит ли это, что после завершения Promise.race можно просто забыть про те промисы, которые проиграли гонку? Оказывается, нет. В 2017 году была описана интересная утечка памяти в Promise.race https://github.com/nodejs/node/issues/17469#issuecomment-685216777. Эта утечка интересна не сама по себе (мне кажется, Promise.race не так часто используют), а тем, что она представляет собой очень показательный пример утечки памяти в js через замыкания. Рассмотрим следующие тезисы.
1. Промис сохраняет свой результат все время, которое он живет.
Некоторые разработчики считают, что если мы не используем результат, который вернул промис, то он освободит память сразу после того, как промис завершится. Это не так! Результат промиса сохраняется в его внутреннем свойстве result все время, пока живет (= ссылочно доступен) сам промис.
2. Также, если промис зарезолвился, это еще не значит, что данные внутри его функции-исполнителя (функция, которую передали в конструктор промиса) больше не удерживаются в памяти. Нет, они могут удерживаться в памяти, например, если внутри исполнителя был setTimeout.
3. Рассмотрим следующий код и попробуем память, когда из памяти будет удален “super string”.
const resolveString = new Promise((resolve) => resolve("super string"));
const neverResolve = new Promise(() => {});
const promises = [resolveString, neverResolve];
const p = new Promise((resolve, reject) => {
for (const promise of promises) {
Promise.resolve(promise).then(resolve, reject);
}
});
В данном случае neverResolve завис в памяти, а с ним и весь родительский промис p. Результат промиса resolveString сохранился как внутренее свойство result объекта p. Если “super string” - это тяжелые данные, то мы получим существенную утечку памяти. По всей видимости, механизм утечки памяти в Promise.race аналогичен вышеизложенному.
GitHub
`Promise.race` lead to memory leak · Issue #17469 · nodejs/node
Version: v9.2.0 and v8.9.1, probably other version also affected Platform: linux Subsystem: - I run this code inside docker with -m 100m --memory-swap 100m , and then the program crash after few se...
❤1👍1🤡1
Forwarded from S0ER
Разделение ответственности в UI компонентах
Привет, на связи @devmargooo и сегодня я хотела бы рассказать свои мысли насчет разделения ответственности в UI компонентах. В своей “Чистой архитектуре” Р. Мартин пишет, что принцип единственной ответственности (SRP) является следствием закона Конвея и определяет, что лучшей является такая структура программной системы, при котором каждый модуль может быть изменен только вследствие удовлетворения интересов одного единственного актора. На мой взгляд, при разработке библиотеки UI компонентов удобно использовать схожий принцип, который можно сформулировать следующим образом: каждая логическая зона UI может менять свое состояние вследствие изменения конфигурации одного и только одного компонента в коде. Под “логической зоной” я пониманию небольшой кусочек UI, который несет полезную нагрузку для пользователя и может находится в разных состояниях. Разберем на примере текстового инпута. В нем я выделяю следующие логические зоны: поле ввода (возможные состояния - пустое, непустое, задизабленное, с ошибкой), крестик возле инпута (возможные состояния - присутствует, отсутствует), иконка возле поля ввода, подпись под полем ввода. Библиотеки UI компонентов часто разрабатывают таким образом, что в них есть “самые базовые компоненты” (например, Input), и компоненты, которые построены на основе этих “самых базовых компонентов” (ErrorInput, LabelInput, IconInput etc) по принципу “матрешки”. Таким образом, нам нужно следить, чтобы в этой иерархии изменять состояние каждой логической зоны мог только компонент! Например, возможность рендера иконки рядом с полем ввода должен иметь только один компонент - или Input, или IconInput, и тд. Рассмотрим следующий пример реализации Input и ErrorInput на React:
При таком подходе возможна ситуация, когда в ErrorInput будут одновременно переданы пропсы
Привет, на связи @devmargooo и сегодня я хотела бы рассказать свои мысли насчет разделения ответственности в UI компонентах. В своей “Чистой архитектуре” Р. Мартин пишет, что принцип единственной ответственности (SRP) является следствием закона Конвея и определяет, что лучшей является такая структура программной системы, при котором каждый модуль может быть изменен только вследствие удовлетворения интересов одного единственного актора. На мой взгляд, при разработке библиотеки UI компонентов удобно использовать схожий принцип, который можно сформулировать следующим образом: каждая логическая зона UI может менять свое состояние вследствие изменения конфигурации одного и только одного компонента в коде. Под “логической зоной” я пониманию небольшой кусочек UI, который несет полезную нагрузку для пользователя и может находится в разных состояниях. Разберем на примере текстового инпута. В нем я выделяю следующие логические зоны: поле ввода (возможные состояния - пустое, непустое, задизабленное, с ошибкой), крестик возле инпута (возможные состояния - присутствует, отсутствует), иконка возле поля ввода, подпись под полем ввода. Библиотеки UI компонентов часто разрабатывают таким образом, что в них есть “самые базовые компоненты” (например, Input), и компоненты, которые построены на основе этих “самых базовых компонентов” (ErrorInput, LabelInput, IconInput etc) по принципу “матрешки”. Таким образом, нам нужно следить, чтобы в этой иерархии изменять состояние каждой логической зоны мог только компонент! Например, возможность рендера иконки рядом с полем ввода должен иметь только один компонент - или Input, или IconInput, и тд. Рассмотрим следующий пример реализации Input и ErrorInput на React:
interface InputProps {
value: string;
setValue: (newValue: string) => void;
icon?:string;
}
const Input = ({value, setValue, icon}:InputProps) => (
<div className="input">
{icon && <div className="icon">{icon}</div>}
<input type="text" value={value} onChange={(e) => setValue(e.target.value)}/>
</div>
)
interface ErrorInputProps extends InputProps {
is_error?: boolean;
}
const ErrorInput = (props:ErrorInputProps) => (
<div className="error_input">
{props.is_error && <div className="error_icon">X</div>}
<Input {...props}/>
</div>
)При таком подходе возможна ситуация, когда в ErrorInput будут одновременно переданы пропсы
is_error и icon и в одной и той же логической зоне иконки будет отрендерено сразу две иконки, одна поверх другой. Следовательно,важно следить за тем, чтобы логическую зону иконки мог изменять только один компонент - в нашем случае это компонент Input. В своей практике я видела достаточно много багов, попавших на продакшн вследствие нарушения этого принципа.🤡1
Forwarded from S0ER
Как решать литкод
Всем привет, на связи снова @devmargooo и сегодня мы поговорим с вами о задачках с литкода. В то время, когда многие говорят о том, стоит ли вообще программисту тратить свое ценное время на решение задачек, преступно мало, на мой скромный взгляд, говорят о том, а как же их все-таки решить, эти задачки? В мануалах с ютуба все просто: блоггер читает условие и дальше решение зреет в его голове само собой, но на практике у многих людей почему-то так не происходит, сколько бы они не сидели перед ноутбуком и не вглядывались в свеженаписанный function declaration. Итак, мой способ - это идти к общему правилу от частного случая, он же метод индукции. Для этого нужно искусственно сократить мощность множества поступающих на вход данных, короче говоря, решить задачу для одного частного случая, причем максимально простого. В вашей функции на вход подаются число? Пускай это будет число 1. Строки? Возьмите строку из одного символа. Двоичные матрицы? Возьмите матрицу из одного элемента, максимально простого. И затем решите задачу для этого элемента. Как правило, такое решение не составляет труда, а написанный код не похож на свой финальный вариант. Далее возьмите еще один частный случай и решите задачу для него. Подумайте, можно ли объединить первые два случая в общее правило? Решите задачу для еще одного-двух случаев, и в этом момент вы уже начнете замечать закономерности, которые приведут вас к общему правилу. Дальше берите на вход все новые и новые виды входных данных, для которых написанное правило не работает, и решайте задачу для них, до тех пор, пока для всех возможных видов данных ваша задача не будет решена.
Всем привет, на связи снова @devmargooo и сегодня мы поговорим с вами о задачках с литкода. В то время, когда многие говорят о том, стоит ли вообще программисту тратить свое ценное время на решение задачек, преступно мало, на мой скромный взгляд, говорят о том, а как же их все-таки решить, эти задачки? В мануалах с ютуба все просто: блоггер читает условие и дальше решение зреет в его голове само собой, но на практике у многих людей почему-то так не происходит, сколько бы они не сидели перед ноутбуком и не вглядывались в свеженаписанный function declaration. Итак, мой способ - это идти к общему правилу от частного случая, он же метод индукции. Для этого нужно искусственно сократить мощность множества поступающих на вход данных, короче говоря, решить задачу для одного частного случая, причем максимально простого. В вашей функции на вход подаются число? Пускай это будет число 1. Строки? Возьмите строку из одного символа. Двоичные матрицы? Возьмите матрицу из одного элемента, максимально простого. И затем решите задачу для этого элемента. Как правило, такое решение не составляет труда, а написанный код не похож на свой финальный вариант. Далее возьмите еще один частный случай и решите задачу для него. Подумайте, можно ли объединить первые два случая в общее правило? Решите задачу для еще одного-двух случаев, и в этом момент вы уже начнете замечать закономерности, которые приведут вас к общему правилу. Дальше берите на вход все новые и новые виды входных данных, для которых написанное правило не работает, и решайте задачу для них, до тех пор, пока для всех возможных видов данных ваша задача не будет решена.
🔥5🤡1
Forwarded from S0ER
Брендированные типы в typescript
Привет, с вами снова @devmargooo и сегодня мы с вами поговорим о типизации в приложении на typescript. Структурная типизация в typescript, в отличие от номинативной, определяет совместимость типов, основываясь не на названии типа, а на его наборе полей. В этом структурная типизация похожа на утиную: если это выглядит как утка, плавает как утка и крякает как утка, то, вероятно, это утка. К сожалению, это может приводить к проблемам. Следующий код не приведет к ошибке компиляции, несмотря на то, что тип
Тип
Номинативные типы работают по-другому - они совместимы только при явном использовании. К сожалению, встроенной поддержки таких типов в 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>;
👍3🤡1
Forwarded from S0ER
Решение проблемы избыточных состояний через конечные автоматы
Часто замечаю в коде у фронтенд-разработчиков такой паттерн, как выражение одного логического состояния через несколько состояний в коде. Рассмотрим, например, такой код на React, который описывает состояние некоторой формы:
Здесь разработчик создает целых три разных независимых состояний в коде (состояние ошибки, состояние загрузки, состояние успеха), но логически весь этот код отвечает за состояние формы - то есть за одно и то же состояние. Это одна форма, которая может либо находиться в одном из четырех состояний:
1. в состоянии загрузки
2. в состоянии ошибки
3. в состоянии успеха
4. в состоянии готовности к редактированию.
Несложно посчитать, что код выше сгенерирует нам целых восемь различных состояний вместо четырех необходимых. Помимо запутанности и сложночитаемости, такой код плох тем, что мы генерируем недостижимые состояния, которые непонятно, как обрабатывать. Например, что делать, если у нас одновременно есть ошибка и переменная isSuccessful равна true? Скорее всего, программист выберет какое-то одно состояние как приоритетное, но так или иначе, такой код будет порождать запутанность и баги.
Выход из этой ситуации - это использование конечных автоматов. Конечный автомат - это математическая модель, описывающая конечный набор возможных состояний и определяющая, что автомат может находится только в одном из этих состояний в конкретный момент времени. Также автомат может переходить из одного состояния в другое. В коде на React конечный автомат можно довольно создать, используя редюсер, а возможные состояния удобно описываются через тип-сумму:
Созданные formReducer и initialState мы можем использовать в нашем компоненте через useReducer. Таким образом, мы получили удобное декларативное описание возможных состояний нашей системы, а также совокупность переходов из одного состояния в другое.
Часто замечаю в коде у фронтенд-разработчиков такой паттерн, как выражение одного логического состояния через несколько состояний в коде. Рассмотрим, например, такой код на 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. Таким образом, мы получили удобное декларативное описание возможных состояний нашей системы, а также совокупность переходов из одного состояния в другое.
👍4😭2🤡1
Последний пост в этом канале был несколько месяцев назад, и я поняла, что хочу оживить его. За это время я успела сменить команду и получить много разного интересного опыта, которым буду делиться с вами 🥰
Сегодня хочу коснуться такой темы, как стейт менеджеры. Я с огромным удовольствием посмотрела доклад Дмитрия Бабина “Вам не нужен 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 брейкпойнт дебаггера и в два счета нахожу в колстеке виновника.
Таким образом, два последних пункта, про которые я пишу - удобные девтулзы и один сеттер данных, в который можно поставить дебаггер - для меня принципиальны. Поэтому я уже много лет остаюсь верной редаксу: мне не нужны суперфичи в стейт менеджере, мне нужны удобные девтулзы для поддержки и дебага приложения. Ни один другой стейт менеджер, ровно как и нативные фичи реакта (контекст, хуки) такой удобный дебаг для меня не предоставляют.
Сегодня хочу коснуться такой темы, как стейт менеджеры. Я с огромным удовольствием посмотрела доклад Дмитрия Бабина “Вам не нужен 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 брейкпойнт дебаггера и в два счета нахожу в колстеке виновника.
Таким образом, два последних пункта, про которые я пишу - удобные девтулзы и один сеттер данных, в который можно поставить дебаггер - для меня принципиальны. Поэтому я уже много лет остаюсь верной редаксу: мне не нужны суперфичи в стейт менеджере, мне нужны удобные девтулзы для поддержки и дебага приложения. Ни один другой стейт менеджер, ровно как и нативные фичи реакта (контекст, хуки) такой удобный дебаг для меня не предоставляют.
YouTube
🎙️ Дмитрий Бабин - Вам не нужен state менеджер (react, redux, zustand, reatom, state management)
А что такое state менеджер, как писать бизнес логику в react, можно ли писать логику на react без библиотек, эти и многие другие вопросы мы с вами поднимем в рамках этого доклада. Попробуем использовать разные библиотеки и сравнить их по многим критериям…
🔥7👍2👎2🥰2🤡1
Небольшой лайфхак.
Допустим, у вас есть проект и есть библиотека компонентов, которую вы используете в проекте. Вы делаете новый компонент в библиотеке. Для того, чтобы проверить, как он интегрируется с проектом, не обязательно релизить новую версию библиотеки - достаточно просто сбилдить библиотеку и подменить сборку библиотеки в node modules вашего проекта на только что собранную вами. Если ваш проект на next.js, то необходимо еще и удалить собранный next-ом билд проекта и пересобрать заново через next dev.
Допустим, у вас есть проект и есть библиотека компонентов, которую вы используете в проекте. Вы делаете новый компонент в библиотеке. Для того, чтобы проверить, как он интегрируется с проектом, не обязательно релизить новую версию библиотеки - достаточно просто сбилдить библиотеку и подменить сборку библиотеки в node modules вашего проекта на только что собранную вами. Если ваш проект на next.js, то необходимо еще и удалить собранный next-ом билд проекта и пересобрать заново через next dev.
🔥10🤡2
Возможно, я кого-то удивлю, но "клиентские компоненты" в next.js рендерятся на... сервере. А затем гидратируются на клиенте, и поэтому код таких компонентов прилетает в браузер.
В отличие от них, серверные компоненты не гидратируются на клиенте, а рендерятся только на сервере.
В отличие от них, серверные компоненты не гидратируются на клиенте, а рендерятся только на сервере.
👌5🤡5👍4
В чем основные преимущества серверных компонентов перед клиентскими в Next.js?
Серверные компоненты рендерятся только на сервере. Браузер не получает js код серверных компонентов, а получает только json-подобное описание необходимомого virtual dom, называемое rsc payload. За счет этого бандл становится меньше.
Второе серьезное преимущество - это поддержка streaming: сервер не дожидается, пока все дерево компонентов будет готово, а отправляет rsc payload по мере готовности, чтобы браузер мог отобразить то, что возможно, как можно скорее. На месте неготовых компонентов будут плейсхолдеры, и браузер заменит их на компоненты сразу, как получит их rsc payload с сервера.
Серверные компоненты рендерятся только на сервере. Браузер не получает js код серверных компонентов, а получает только json-подобное описание необходимомого virtual dom, называемое rsc payload. За счет этого бандл становится меньше.
Второе серьезное преимущество - это поддержка streaming: сервер не дожидается, пока все дерево компонентов будет готово, а отправляет rsc payload по мере готовности, чтобы браузер мог отобразить то, что возможно, как можно скорее. На месте неготовых компонентов будут плейсхолдеры, и браузер заменит их на компоненты сразу, как получит их rsc payload с сервера.
🔥15
Сегодня помогала фронтендеру в чате разобраться с проблемой.
Собственно, проблема: в верстке футер не достает до правого края, хотя указана ширина 100%. Такие проблемы обычно возникают, когда какой-то потомок выпал из контейнера. Например, у потомка указана ширина 100% и у родительского контейнера есть паддинги, из-за паддингов суммарно ширина становится больше 100% и вот уже потомок выпал из контейнера.
Рецепт дебага:
1. Нам нужно найти, какой элемент вывалился из контейнера. Идем в файл с html разметкой (или корневой компонент в вашем любимом фреймворке)
2. Комментируем ВСЕ. Проблема исчезнет, как и вся верстка с сайта.
3. Поочередно, по одной секции страницы, раскомментируем обратно
4. Та секция, на которой проблема снова появилась, и есть проблемная. В ней обычно легко найти вывалившийся элемент при помощи девтулзов браузера. Если нет, то рекурсивно повторяем историю с комментированием, но уже в рамках отдельной секции.
P.S. Лендинг со скриншота я создала за пару минут в https://v0.dev. Спасибо Сергею и его каналу https://t.iss.one/DragorWW_space за то, что регулярно освещает крутые нейронки для работы!
Собственно, проблема: в верстке футер не достает до правого края, хотя указана ширина 100%. Такие проблемы обычно возникают, когда какой-то потомок выпал из контейнера. Например, у потомка указана ширина 100% и у родительского контейнера есть паддинги, из-за паддингов суммарно ширина становится больше 100% и вот уже потомок выпал из контейнера.
Рецепт дебага:
1. Нам нужно найти, какой элемент вывалился из контейнера. Идем в файл с html разметкой (или корневой компонент в вашем любимом фреймворке)
2. Комментируем ВСЕ. Проблема исчезнет, как и вся верстка с сайта.
3. Поочередно, по одной секции страницы, раскомментируем обратно
4. Та секция, на которой проблема снова появилась, и есть проблемная. В ней обычно легко найти вывалившийся элемент при помощи девтулзов браузера. Если нет, то рекурсивно повторяем историю с комментированием, но уже в рамках отдельной секции.
P.S. Лендинг со скриншота я создала за пару минут в https://v0.dev. Спасибо Сергею и его каналу https://t.iss.one/DragorWW_space за то, что регулярно освещает крутые нейронки для работы!
👍7❤4
На днях спросили, какие темы в Javascript нужно знать для стажировки по этому направлению. Приведу полный список здесь:
- Переменные - let, const
- Условия - if else
- Циклы for, for of, for in, forEach, while
- Функции
- Типы данных (примитивы и объекты). Тип Symbol стажерам знать не обязательно :)
- Методы строк, методы массивов, методы объектов
- Промисы, async/await
- Ключевое слово this, bind, call, apply
- Таймеры: setTimeout, setInterval
Это основы Javascript, которые необходимы стажеру для того, чтобы начать практиковаться. Все остальное можно выучить уже позже😊
- Переменные - let, const
- Условия - if else
- Циклы for, for of, for in, forEach, while
- Функции
- Типы данных (примитивы и объекты). Тип Symbol стажерам знать не обязательно :)
- Методы строк, методы массивов, методы объектов
- Промисы, async/await
- Ключевое слово this, bind, call, apply
- Таймеры: setTimeout, setInterval
Это основы Javascript, которые необходимы стажеру для того, чтобы начать практиковаться. Все остальное можно выучить уже позже😊
1❤13
В одном из чатиков обещала рассказать, как я готовлю условные типы в 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, в противном случае - то же, что и было в исходном типе1❤10🤯7👍5🔥2
Media is too big
VIEW IN TELEGRAM
Вот такой вот сайт я сделала себе за день при помощи нейросети https://v0.dev/, при этом бОльшую часть времени работы я потратила на тексты и на настройку хостинга. Закинула пропмтом тему сайта и понравившуюся мне цветовую схему, и сервис сгенерировал мне готовый проект на next.js. Мне осталось только скачать его, заменить тексты на свои и захостить :)
Потыкать можно здесь: https://devmargooo.ru/
Потыкать можно здесь: https://devmargooo.ru/
🔥7🤯3
Как в next.js на серверной стороне определить, десктопную или мобильную версию сайта рисовать?
В популярных библиотеках для React существует много хуков, которые позволяют определить версию лейаута - мобильную или десктопную. Однако они все работают на браузерной стороне, а в next.js может потребоваться определить лейаут на серверной стороне, чтобы сразу отдать десктопную или мобильную верстку. Универсального рецепта у меня нет, но есть достаточно хороший:
1. Нам нужно получить заголовок user agent. В next это делается при помощи функции headers.
2. В мобильных браузерах обычно есть слова
В популярных библиотеках для 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.❤10