Псевдо-класс :not() — одна из самых мощных фич CSS, которую часто используют для исключений, но мало кто знает, что она может делать намного больше. В этом посте мы разберемся, как можно использовать
:not() для улучшения гибкости и точности ваших стилей.Вы наверняка знаете, что :not() используется для исключения элементов с определенным классом или позицией в списке. Например, стиль применяется ко всем элементам .link, кроме последних в списке. Однако :not() позволяет комбинировать несколько условий. Код применяет стиль ко всем img без атрибута class и не являющихся первыми детьми в родительском элементе. Это возможно благодаря тому, что :not() принимает несколько селекторов, разделённых запятыми.
/* Базовое применение */
.link:not(:last-child) {
margin-left: 1rem;
}
/* Применение для всех img, кроме тех, у которых есть атрибут class */
img:not([class], :first-child) {
margin-block-start: var(--ds-typography-img-margin-block-start, var(--_ds-typography-main-margin));
}Что если вы хотите применить стиль только к тем элементам, которые не содержат в себе определённого соседа? Это легко сделать, используя комбинацию :not() и :has(). В примере стиль background-color: lightblue применяется ко всем параграфам <p>, за которыми не следует элемент <h2>. Это позволяет точно контролировать, какие элементы подвергать стилизации, не добавляя лишних классов или элементов разметки.
<body>
<h1>Париж</h1>
<p>Столица и крупнейший город Франции...</p>
<h2>История</h2>
<p>Париж вырос на месте поселения...</p>
<p>Поселение располагалось на безопасном острове...</p>
</body>
/* Применяем стиль только к параграфам, за которыми не следует элемент h2 */
p:not(:has(+ h2)) {
background-color: lightblue;
}Псевдо-класс :not() — это просто огонь-фича для тех, кто любит делать код проще и понятнее. Он позволяет исключать элементы по разным условиям, что значительно упрощает создание сложных селекторов. В отличие от старых методов, :not() даёт вам больше свободы и точности.
С его помощью можно создавать более чистые и понятные разметки, которые легко подстраиваются под изменения в структуре документа. Это как улучшенная версия селекторов :first-child или :last-child, только с гораздо большими возможностями.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10❤3🐳1
Тестирование — это не просто «привет, юнит-тесты» и «проверим кнопку». Когда речь идет о больших приложениях с кучей состояний, анимаций и взаимодействий, интерфейсы становятся одним из самых уязвимых мест. И, если не тестировать интерфейсные взаимодействия должным образом, то рано или поздно придётся искать баги, скрытые за пользовательскими проблемами.
✅ Интерактивность и поведение: Простой пример — форма, которая не отправляется после клика, или чекбокс, который не обновляет свой статус. Такие вещи сложно отловить вручную, но они могут стать причиной огромного недовольства пользователей.✅ Кросс-браузерность и адаптивность: Интерфейс может выглядеть идеально в Chrome, но ломаться в Safari или на мобильном. С тестами таких проблем можно избежать, проверяя поведение компонентов на разных устройствах и браузерах.✅ UI/UX баги: Строго говоря, это не «классовые» баги, а проблемы, которые влияют на восприятие приложения. Несоответствие дизайну, неправильные анимации — всё это может уйти незамеченным в процессе обычного тестирования, но сказаться на восприятии вашего продукта.
👀 Cypress: Простой и мощный инструмент для энд-ту-энд тестирования. Он позволяет тестировать, как ваш интерфейс ведет себя в реальных сценариях: клики, заполнение форм, навигация, и многое другое. Cypress особенно удобен для динамичных SPA-приложений, где важно протестировать все возможные переходы и взаимодействия.👀 Если вам нужно больше гибкости, попробуйте Playwright. Он поддерживает тестирование нескольких браузеров и идеально подходит для тестирования UI на разных платформах, таких как Chrome, Firefox и WebKit. А ещё, в отличие от Cypress, Playwright поддерживает тестирование мобильных устройств из коробки.👀 React Testing Library: Если вы работаете с React, этот инструмент поможет вам тестировать компоненты с учётом пользовательских взаимодействий. Он фокусируется на тестах, которые проверяют не только логику, но и правильное поведение в контексте UI. Например, как компоненты реагируют на пользовательский ввод или как они отображаются при разных состояниях.👀 В случае, если вам нужно тестировать поведение интерфейса в браузере, Puppeteer — это тот инструмент, который поможет вам автоматизировать тесты в реальных браузерах. Это идеальный выбор для UI-тестов, где важен контроль над браузерными событиями и точность.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤1
Связность и сцепленность. Почему код живёт или умирает.
Недавно наткнулся на пост Темы Сенюкова из Кинопоиска про Cohesion и Coupling. Кажется, это одни из тех базовых понятий, которые ты вроде знаешь, но понимаешь только после кучи сделанных ошибок.
С опытом начинаешь видеть закономерность: код умирает не потому, что «технология устарела» или «всё переписали на React 19». Он умирает, потому что у него нарушен баланс — внутри всё плохо связано, а снаружи всё переплетено.
Когда связность (cohesion) низкая — модуль делает всё подряд: загружает данные, форматирует дату, логирует аналитику и варит кофе юзеру. Заходишь туда через полгода — и не понимаешь, что и где.
Когда сцепленность (coupling) высокая — любое изменение где-то «там» ломает всё «здесь». Изменили API? Привет, бесконечный refactor. Поменяли store? Упало полстраницы.
В какой-то момент я перестал смотреть на код просто как на функции и компоненты. Теперь я думаю о нём как о «разговорах» между кусками приложения. Хороший код — это когда эти разговоры короткие и по делу. Плохой — когда все орут непонятно что.
Вот пара мыслей, которые реально помогают:
🟢 Делайте компоненты, которые умеют ровно одно. Остальное пусть решают «соседи».
🟢 Прокидывайте зависимости явно — пусть всё, что нужно компоненту, приходит снаружи.
🟢 Разделяйте слои. Данные, логика, UI — три мира, не обязанные знать детали друг друга.
🟢 И самое главное — не бойтесь «резать» код. Маленькие куски легче понимать, менять и тестировать.
✅ Это те вещи, которые определяют, живёт ли ваш проект дольше полугода
Недавно наткнулся на пост Темы Сенюкова из Кинопоиска про Cohesion и Coupling. Кажется, это одни из тех базовых понятий, которые ты вроде знаешь, но понимаешь только после кучи сделанных ошибок.
С опытом начинаешь видеть закономерность: код умирает не потому, что «технология устарела» или «всё переписали на React 19». Он умирает, потому что у него нарушен баланс — внутри всё плохо связано, а снаружи всё переплетено.
Когда связность (cohesion) низкая — модуль делает всё подряд: загружает данные, форматирует дату, логирует аналитику и варит кофе юзеру. Заходишь туда через полгода — и не понимаешь, что и где.
Когда сцепленность (coupling) высокая — любое изменение где-то «там» ломает всё «здесь». Изменили API? Привет, бесконечный refactor. Поменяли store? Упало полстраницы.
В какой-то момент я перестал смотреть на код просто как на функции и компоненты. Теперь я думаю о нём как о «разговорах» между кусками приложения. Хороший код — это когда эти разговоры короткие и по делу. Плохой — когда все орут непонятно что.
Вот пара мыслей, которые реально помогают:
🟢 Делайте компоненты, которые умеют ровно одно. Остальное пусть решают «соседи».
🟢 Прокидывайте зависимости явно — пусть всё, что нужно компоненту, приходит снаружи.
🟢 Разделяйте слои. Данные, логика, UI — три мира, не обязанные знать детали друг друга.
🟢 И самое главное — не бойтесь «резать» код. Маленькие куски легче понимать, менять и тестировать.
✅ Это те вещи, которые определяют, живёт ли ваш проект дольше полугода
Telegram
ТОП - Тёма о программировани
Cohesion и Coupling 🧩🔗
Здарова, работяги!
Если очень коротко: хорошая архитектура — это высокая связность внутри модулей (cohesion) и низкая связанность между ними (coupling). Эти два термина отлично объясняют, почему код либо живёт годами, либо рассыпается…
Здарова, работяги!
Если очень коротко: хорошая архитектура — это высокая связность внутри модулей (cohesion) и низкая связанность между ними (coupling). Эти два термина отлично объясняют, почему код либо живёт годами, либо рассыпается…
👍12❤2
Когда мы работаем с анимациями в CSS, важно учитывать, какие свойства задействованы. Некоторые из них могут значительно снизить производительность страницы, тогда как другие обеспечат плавность и быстрое отображение.
Анимация свойств, таких как width, height, margin, padding, top и left, требует от браузера выполнения нескольких ресурсоёмких шагов: Reflow (пересчёт размеров и расположения элементов), Repaint (перерисовка частей страницы) и отображение на экране. Эти процессы могут значительно замедлить работу страницы, особенно при большом количестве элементов, что негативно сказывается на её производительности.
Для повышения производительности веб-анимаций рекомендуется использовать свойства, обрабатываемые графическим процессором (GPU), вместо центрального процессора (CPU). Это позволяет избежать лишних вычислений и ускоряет отображение, особенно при анимации таких свойств, как transform (например, translate, scale, rotate) и opacity (прозрачность). В этих случаях браузеру не нужно пересчитывать размеры элементов или перерисовывать всю страницу, так как изменения происходят на уровне графики, что значительно улучшает производительность.
/* Когда вы анимируете left, браузер выполняет перерасчёт и перерисовку страницы. Этот способ медленный, так как каждый сдвиг элемента требует выполнения операций reflow и repaint. */
.element {
transition: left 0.5s ease;
}
/* При использовании transform, браузер просто сдвигает элемент на графическом уровне, избегая дополнительных перерасчётов. Здесь браузер применяет изменения только на уровне GPU, что делает анимацию плавной и быстрой. */
.element {
transition: transform 0.5s ease;
}Please open Telegram to view this post
VIEW IN TELEGRAM
👍15🔥9❤3
При создании форм часто встречаются обязательные поля. Они могут быть заполнены верно или нет. Для стилизации этих состояний обычно используют псевдо-классы
:valid и :invalid. Эти классы применяются сразу после загрузки страницы, даже если пользователь ещё не успел взаимодействовать с полем. Это может раздражать из-за некорректного отображения. Рассмотрим, как можно исправить и улучшить ситуацию.<<!-- Первое поле с логином зелёное (корректно заполнено). Второе поле с паролем красное (пусто и недействительно) -->
<body>
<form class="form">
<div class="form__group">
<label for="name">Введите логин</label>
<input id="name" type="text" value="melnik909" required>
</div>
<div class="form__group">
<label for="password">Введите пароль</label>
<input id="password" type="password" required>
</div>
<button>Войти</button>
</form>
</body>
<style>
input:invalid {
box-shadow: 0 0 10px red;
}
input:valid {
box-shadow: 0 0 10px green;
}
</style>Для предотвращения преждевременного применения стилей добавлены псевдо-классы
:user-valid и :user-invalid, которые активируются при взаимодействии пользователя с полем. Стили применяются только после ввода данных. Давайте заменим старые псевдо-классы на новые:input:user-invalid {
box-shadow: 0 0 10px red;
}
input:user-valid {
box-shadow: 0 0 10px green;
}Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤5🔥2
Forwarded from xCode Journal
Please open Telegram to view this post
VIEW IN TELEGRAM
😁38👎4🔥4👍2👀2
#react #вакансия
Позиция: Fullstack Web Developer (React + Next.js)
Компания: MiningPool
Формат работы: удаленка
Занятость: полная
Вилка: $2500-$4000
Ты построишь клиентский кабинет: UI для мониторинга, биллинга, управления воркерами и токенами. Это роль с упором на React и Next.js, с лёгкой интеграцией backend API, аутентификацией и авторизацией.
Зоны ответственности:
* Реализация интерфейса Dashboard: статистика хешрейта, состояние воркеров, лимиты и токены доступа, история начислений
* Интеграция с Clerk (аутентификация, RBAC)
* Подключение REST API (на Rust)
* Фронтовая бизнес-логика: генерация воркеров, отображение статусов, установка ограничений
* Создание простых визуализаций (charts, таблицы, фильтры)
Технологии:
* React, Next.js, Tailwind, shadcn/ui
* Clerk SDK (auth)
* REST API (axios, react-query или SWR)
* PostgreSQL (через API), Supabase.
Требования:
* 2+ года опыта с React / Next.js
* Уверенная работа с REST API и Auth SDK
* Умение быстро проектировать UI на Tailwind или shadcn
* Знание баз данных на уровне SQL и умение читать EXPLAIN — большой плюс
Для связи и отправки резюме:
@dishsh
Позиция: Fullstack Web Developer (React + Next.js)
Компания: MiningPool
Формат работы: удаленка
Занятость: полная
Вилка: $2500-$4000
Ты построишь клиентский кабинет: UI для мониторинга, биллинга, управления воркерами и токенами. Это роль с упором на React и Next.js, с лёгкой интеграцией backend API, аутентификацией и авторизацией.
Зоны ответственности:
* Реализация интерфейса Dashboard: статистика хешрейта, состояние воркеров, лимиты и токены доступа, история начислений
* Интеграция с Clerk (аутентификация, RBAC)
* Подключение REST API (на Rust)
* Фронтовая бизнес-логика: генерация воркеров, отображение статусов, установка ограничений
* Создание простых визуализаций (charts, таблицы, фильтры)
Технологии:
* React, Next.js, Tailwind, shadcn/ui
* Clerk SDK (auth)
* REST API (axios, react-query или SWR)
* PostgreSQL (через API), Supabase.
Требования:
* 2+ года опыта с React / Next.js
* Уверенная работа с REST API и Auth SDK
* Умение быстро проектировать UI на Tailwind или shadcn
* Знание баз данных на уровне SQL и умение читать EXPLAIN — большой плюс
Для связи и отправки резюме:
@dishsh
❤3👎3🔥2🐳1
Когда говорим о производительности веб-приложений, вспоминаем уменьшение веса страниц и оптимизацию кода. Однако есть requestIdleCallback — это API для запуска задач в моменты, когда браузер не занят важными операциями, например, рендерингом или обработкой событий. Это идеальный способ для фоновых задач, таких как загрузка или обработка данных, без влияния на пользовательский интерфейс и основные операции.
Основной сценарий использования requestIdleCallback — это выполнение задач, которые не требуют немедленного выполнения, но важно, чтобы они не блокировали основной поток. Например, обновление данных или выполнение фона операций, которые не затрагивают работу интерфейса. Представьте, что нужно загрузить данные с сервера, но при этом не хотите, чтобы это замедляло работу с интерфейсом. В такие моменты requestIdleCallback поможет вам аккуратно выполнить это задание в моменты простоя браузера.
/* Предположим, вы хотите загрузить данные с API в фоновом режиме. Вместо того чтобы инициировать запрос сразу и блокировать основной поток, можно использовать requestIdleCallback: */
function fetchDataInIdleTime() {
requestIdleCallback(() => {
fetch('/some-api')
.then(response => response.json())
.then(data => {
console.log('Data loaded in idle time:', data);
})
.catch(error => console.error('Error loading data:', error));
});
}
fetchDataInIdleTime();— Мы создаём функцию fetchDataInIdleTime(), которая запускает requestIdleCallback.
— Внутри колбэка выполняем асинхронный запрос к серверу.
— Запрос будет выполнен в момент, когда браузер освободится от важных задач, таких как рендеринг или обработка событий.
— Таким образом, мы делаем загрузку данных менее приоритетной и не нагружаем браузер, пока он не свободен.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥3❤2👀2
Технологии не стоят на месте, и в 2025 году Intersection Observer API продолжает развиваться и становится важным инструментом для веб-разработчиков. Этот API не только помогает улучшить производительность, но и заметно повышает качество взаимодействия с пользователем. Давайте разберемся, почему вам стоит обратить на него внимание, и как он может упростить вашу жизнь.
Intersection Observer API отслеживает видимость элементов, оптимизируя загрузку контента. Он не требует постоянного мониторинга прокрутки или размера окна. Вместо этого, API реагирует только на изменения видимости, активируя логику, например, загрузку изображений или анимаций, когда пользователь достигает нужного места. Это сокращает ненужные рендеры и повышает производительность. Меньше вычислений, меньше данных — это особенно важно на устройствах с низкими характеристиками.
const observer = new IntersectionObserver((entries, observer) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
// Загружаем изображение, когда оно попадает в область видимости
entry.target.src = entry.target.dataset.src;
observer.unobserve(entry.target);
}
});
});
const images = document.querySelectorAll('img.lazy');
images.forEach(img => observer.observe(img));— Предположим, вы хотите отложить загрузку изображений до тех пор, пока они не окажутся в области видимости.
— Здесь мы создаём новый IntersectionObserver.
— Для каждого изображения с классом .lazy, как только оно появляется в зоне видимости, происходит загрузка изображения.
— Весь этот процесс запускается только в нужный момент, что минимизирует ненужные операции.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤5
Forwarded from xCode Journal
Вводи в адресную строку Chrome:
chrome://chrome-urls и открываем список всех внутренних страниц браузера: от отладочных тулзов до экспериментальных фич. Внутри:-
chrome://flags → скрытые настройки-
chrome://gpu → информация о работе GPU-
chrome://net-export → отладка сетиPlease open Telegram to view this post
VIEW IN TELEGRAM
👍9❤2🐳1
Адаптивный дизайн изначально базировался на
@media с условием: если ширина экрана меньше 768px, уменьшаем шрифт. Но проблема в том, что компоненты могут адаптироваться по-разному в зависимости от контекста (сайдбар, карточка, модальное окно), даже при неизменном размере экрана. Media queries реагируют только на размер viewport, а не на размеры родителя. Container Queries позволяют учитывать размеры родительского контейнера, что даёт CSS возможность адаптировать компоненты в зависимости от контекста..card {
container-type: inline-size;
}
@container (max-width: 400px) {
.card-noscript {
font-size: 1rem;
}
}• Мы объявляем контейнер с помощью свойства container-type.
• Пишем условие с @container, чтобы адаптировать элементы внутри контейнера.
• Компонент автоматически адаптируется под размеры своего родителя, а не под весь экран.
• Теперь компоненты не зависят от глобальных media queries и могут быть использованы в любом месте без дополнительных хаков или специфичных классов.
• Можно описывать адаптив прямо в компонентах, как это делают дизайнеры в Figma. Теперь ваш CSS гораздо точнее отражает реальные потребности.
• Сокращается использование JS для адаптивных изменений и избавляет от необходимости работать с множеством media queries, что делает код чище.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥8❤1
Forwarded from Технотренды
⚡️ Запускаем крупный розыгрыш призов, где можно выиграть iPhone 17, игровые наушники, клавиатуру и мышь!
Без лишних слов, условия:
1. Подписка на:
— бизнестрендс
— Технотренды
— Блумберг
2. Нажать кнопку «Участвовать» снизу
Итоги будут опубликованы 15 ноября в 18:00 на наших каналах, желаем удачи!
Без лишних слов, условия:
1. Подписка на:
— бизнестрендс
— Технотренды
— Блумберг
2. Нажать кнопку «Участвовать» снизу
Итоги будут опубликованы 15 ноября в 18:00 на наших каналах, желаем удачи!
😁1
Проект начинается с идеальной структуры в src/, но через год появляются папки вроде utils, helpers, components-old, нарушая порядок. Архитектура страдает, так как файлы растут быстрее структуры. Как избежать хаоса и не утонуть в коде?
— Feature-sliced design (FSD)
В проекте можно использовать подход, при котором структура делится не по типу файлов, а по функциональности. Например, вместо создания папок для компонентов и утилит организуется структура вокруг функциональных блоков. В папке src создаются разделы: entities, features, pages и shared. Каждая «фича», например, авторизация или профили пользователей, изолирована и имеет свой пользовательский интерфейс, бизнес-логику и сервисы. Это облегчает масштабирование проекта и предотвращает поломку старых функций при добавлении новых.
— Domain-first подход
Теперь ты называешь папки не components, hooks, utils, а по именам бизнес-областей: auth/, profile/, dashboard/. Это упрощает понимание контекста и делает код более организованным.
— Index-файлы как интерфейсы
Каждый модуль экспортирует наружу только то, что нужно. Это помогает уменьшить сцепленность между модулями и делает импорты предсказуемыми.// Ты исключаешь импорт ненужных частей и делаешь структуру кода более читаемой.
// features/login/index.ts
export { LoginForm } from './ui/LoginForm';
export { useLogin } from './model/useLogin';
— Слои зависимостей
Организуй проект так, чтобы зависимости двигались в одном направлении: от UI → Features → Entities → Shared. Никаких цикличных импортов или «вверх по слоям». Архитектура будет выглядеть как дерево зависимостей, а не как хаотичная паутина.
— TypeScript path aliases: Используй алиасы для упрощения импорта, например: @/shared, @/features/auth.
— ESLint rules: Настрой правила для контроля правильности импортов между слоями.
— Barrel files (index.ts): В каждом модуле используй index.ts для экспортирования публичных интерфейсов. Это поможет сократить количество файлов и сделать структуру более понятной.
— Nx / Turborepo: Эти инструменты идеально подходят для крупных монорепозиториев, где нужно поддерживать чистоту и порядок.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👎1👀1
Forwarded from xCode Journal
Можно импортировать коллекции из Postman, использовать переменные окружения, хранить ключи в системном хранилище и даже кастомизировать интерфейс
Работает просто магически.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍4🔥2
Когда речь заходит об анимациях на фронтенде, мнения расходятся: одни говорят, что для большинства случаев достаточно CSS transitions, а другие утверждают, что только Web Animations API даёт полный контроль над процессом. Давайте разберёмся, что из этого действительно нужно в вашем арсенале.
/* CSS transitions идеальны для UI-элементов, таких как кнопки, модальные окна и спиннеры */
.button {
transition: transform 0.2s ease;
}
.button:hover {
transform: scale(1.05);
}
• Лёгкость в реализации
• Браузер сам оптимизирует процесс анимации
• Подходит для простых эффектов: hover, fade-in/out, микровзаимодействий
• Нельзя ставить анимацию на паузу, изменить скорость или реверсировать её
• Не подходит для сложных или кастомных анимаций
// Это инструмент для более сложных анимаций: от секвенций и кастомных интеракций до scroll-анимаций
el.animate(
[{ transform: 'translateX(0)' }, { transform: 'translateX(100px)' }],
{ duration: 500, easing: 'ease-out', fill: 'forwards' }
);
// Лёгкость в синхронизации
// Можно комбинировать с библиотеками, такими как GSAP или React
// Можно ставить анимацию на паузу, ускорять, реверсировать
// Необходимость писать больше кода, чем для CSSPlease open Telegram to view this post
VIEW IN TELEGRAM
👍7❤4👎1😁1🐳1
Когда-то доступность в веб-разработке воспринималась как что-то дополнительное. Ты просто добавляешь alt-тег, прописываешь aria-label и считаешь, что все сделал. Сегодня все изменилось. Доступность стала неотъемлемой частью UX, SEO и даже бренда.
— Доступность как часть производительности
Теперь доступность тестируется так же, как и производительность. Инструменты вроде Lighthouse, axe-core и SonarLint уже встроены в CI/CD. Ошибки a11y не остаются на потом, а реально блокируют билд, если что-то идет не так.
— AI помогает улучшать доступность
Плагины для VSCode подсказывают семантические ошибки, а такие модели, как GPT, могут автоматически генерировать alt-тексты или адаптировать контент для экранных читалок. Искусственный интеллект становится важным помощником в процессе разработки доступных интерфейсов.
— Voice-first и multimodal интерфейсы
Приложения начинают проектировать с учетом голосового управления, жестов и клавиатуры. Это больше не только для пользователей с особыми потребностями, а универсальный подход, который повышает удобство для всех.
• axe DevTools — проводите автоматические проверки доступности прямо в браузере.
• Polypane / Responsively App — визуализируйте интерфейсы с учетом различных состояний, включая цветовую слепоту и контрастность.
• Figma Contrast & A11y plugins — проектируйте интерфейсы с учетом доступности еще до начала разработки.
• aria-linter и eslint-plugin-jsx-a11y — обязательные инструменты для React/Next проектов.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤3👎1🐳1
Когда мы думаем о
fetch, сразу представляем себе старый добрый запрос: fetch(url).then(r => r.json()). Но современные веб-технологии куда мощнее. Вместе с Streams API и AbortController мы получаем уникальное сочетание, которое упрощает работу с большими данными и позволяет нам создавать более гибкие и быстрые интерфейсы.❗️ Streams API — когда данные приходят по частям
Раньше ответ от сервера загружался целиком, а затем обрабатывался. Сегодня данные поступают по частям, что позволяет работать с ними постепенно. Это особенно полезно для больших JSON, видео и SSE. Мы можем отображать прогресс загрузки и не загружать весь файл в память, что делает работу с большими данными более эффективной и экономит ресурсы браузера.// Пример кода
const res = await fetch('/big.json');
const reader = res.body?.getReader();
let chunks = '';
while (true) {
const { done, value } = await reader.read();
if (done) break;
chunks += new TextDecoder().decode(value);
}❗️ AbortController — контроль над асинхронными операциями
AbortController отменяет запросы и асинхронные операции, если они больше не нужны, например когда пользователь ушёл со страницы. Запрос отменяется через 2 секунды без ответа. Это можно использовать не только для fetch, но и для любых асинхронных операций, которые поддерживают signal.// Пример кода
const controller = new AbortController();
const signal = controller.signal;
fetch('/api/data', { signal });
setTimeout(() => controller.abort(), 2000);❗️ Вместе — это мощный инструмент для реактивных интерфейсов
Объединив эти возможности, мы получаем мощный паттерн для работы с данными в реальном времени: стриминг данных в UI, отображение частичных результатов без загрузочных экранов и экономию памяти. Это улучшает производительность и пользовательский опыт.// Пример кода
const controller = new AbortController();
const res = await fetch('/api/stream', { signal: controller.signal });
const reader = res.body.getReader();
for await (const chunk of streamToAsyncIterator(reader)) {
renderChunk(chunk);
}
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤4👍2👎1🐳1
«Меньше кода» — хорошо, но важно понимать, что это не означает сокращение строк любой ценой. Главная цель здесь — ясность и простота, а не сделать код короче. Давайте разберёмся, как можно уменьшить количество кода, не жертвуя его качеством.
• Не бойтесь удалять лишнее
Каждая функция и условие — это потенциальная точка отказа. Если код не добавляет ценности и не решает задачу, то его лучше удалить. Поддержка меньшего объёма кода позволяет сосредоточиться на более важных аспектах и упрощает развитие проекта. Меньше кода — значит меньше проблем в будущем.
• Повторение — не всегда плохо
Когда в коде появляются 2-3 одинаковые строки, не спешите их абстрагировать. Часто абстракции ради экономии пары строк только делают код сложнее для восприятия. Правило простое: «Не абстрагируй раньше времени, абстрагируй умно». Если повторение не вызывает затруднений, оставьте его.
• Используй возможности JavaScript
Есть ситуации, когда можно заменить несколько строк на одну — и при этом не потерять читаемости. Не бойтесь использовать тернарные операторы, если они действительно упрощают понимание логики. Главное — одна мысль в одну строку.// Вместо:
if (isAdmin) return 'admin'
else return 'user'
// Можно:
return isAdmin ? 'admin' : 'user'
• Компоненты должны быть короткими
Если React-компонент начинает занимать больше 50 строк, подумайте, не пора ли его разделить. Логику можно вынести в хук, а часть верстки — в отдельный подкомпонент. Каждый компонент должен выполнять одну задачу, чтобы код оставался читаемым и легко поддерживаемым.
• Подход как у редактора
Каждый раз, когда добавляете новую строку в код, спросите себя: «Можно ли сделать это проще?» Пытайтесь всегда искать оптимальное решение. Иногда уменьшение кода на пару строк может значительно повысить его читаемость.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤2👎2
В TypeScript 5+ добавили декораторы — это такие штуки, которые делают код понятнее и проще поддерживать. Они похожи на middleware, но работают с классами, методами, полями или параметрами, не ломая логику программы.
function Log(target: any, key: string, denoscriptor: PropertyDenoscriptor) {
const original = denoscriptor.value;
denoscriptor.value = function (...args: any[]) {
console.log(`Call: ${key}(${args.join(', ')})`);
return original.apply(this, args);
};
}
class UserService {
@Log
getUser(id: number) {
return { id, name: 'Alice' };
}
}
new UserService().getUser(42);
// → Call: getUser(42)— Логирование и аналитика. Декоратор @Log записывает вызовы метода getUser, логируя параметры и результат. Это позволяет мониторить вызовы без изменения их логики. Декораторы, такие как @Log, @Track и @MeasureTime, используются для сбора статистики.
— Валидация и проверка аргументов. С помощью декораторов типа @Validate можно автоматически проверять входные данные. Проверка будет происходить автоматически при вызове метода, без дополнительных шагов.
— DI / инъекция зависимостей. Многие фреймворки, такие как Angular и NestJS, активно используют декораторы для инъекции зависимостей (@Injectable, @Component).
— Access control / Guard’ы. Декораторы также могут применяться для контроля доступа, например, @RequireAuth для проверки авторизации перед доступом к страницам или API.
TypeScript преобразует декораторы в вызовы функций, получающих метаданные элементов. Современный синтаксис декораторов основан на ECMAScript proposal и позволяет использовать несколько декораторов для одного элемента, выполняющихся сверху вниз.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍4🔥3👎1🐳1
Forwarded from xCode Journal
Анализ 180 миллионов вакансий показал, какие профессии реально под ударом из-за ИИ:
— С 2023 по 2025 год больше всего не повезло творческим профессиям: вакансий графических дизайнеров стало меньше на 33%, фотографов на 28%, копирайтеров и редакторов — тоже около 28%.
— Зато спрос на ML-специалистов вырос на 40%, специалисты по робототехнике и программисты пока тоже в безопасности — ИИ тут скорее помогает, чем замещает и отнимает работу.
— Единственные, у кого уменьшилось количество вакансий в ИТ-сфере — это у фронтендеров.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👀24👎11🐳4❤3