⚡️ В React Router появились middleware!

В версии 7.9.0 добавили стабильную поддержку middleware 🎉. Теперь можно:

* 🔑 Проверять авторизацию в родительском маршруте и останавливать выполнение дочерних loader
* 📡 Передавать данные из middleware в контекст, доступный в loader и маршрутах
* 🛠 Реализовать общую логику (логирование, редиректы, заголовки) без дублирования

Пример авторизации через middleware:

// routes/_protected.tsx
import { redirect } from "react-router";

export async function middleware({ context }) {
  if (!context.user) {
    throw redirect("/login");
  }
}

👉 Подробнее: https://remix.run/blog/middleware
👉 Документация: https://reactrouter.com/how-to/middleware

⚡️ React Bits — готовые анимированные компоненты для React

Иногда мне присылают полезные сайты — так я и наткнулась на https://reactbits.dev/ 🎉

Это коллекция готовых анимированных компонентов для React + Tailwind: кнопки, переключатели, загрузчики, анимации. Быстро оживляет интерфейс и экономит время разработки.

Последние 8 месяцев я каждые две недели проводила ассессменты фронтенд-разработчиков. Делюсь инсайтами:

✨ Компания и команда в которой человек начинает стажировку играет немаловажную роль. Например, встречались кейсы, когда разработчик с 6 годами опыта получал оценку «джун» — просто потому что его скоуп задач в проекте был сильно ограничен. Причём иногда уже по рассказу кандидата о том, чем он занимался, можно составить определённое мнение о его уровне.

🚀 Большое значение имеет стремление к саморазвитию. Попадались кандидаты, которые честно говорили: «Я просто пишу код, а теорию уже давно забыл».

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

🎬 Всем привет!
Вышел документальный фильм про Vite — https://www.youtube.com/watch?v=bmWQqAKLgT4 (на английском языке).

Фильм рассказывает о том, как появилась идея создания Vite, как стремительно начала расти экосистема, появились плагины, тестовый фреймворк Vitest и конференция ViteConf, впервые объединившая разработчиков из разных экосистем.
Также показано, как Vite стал *де-факто стандартом* современной веб-разработки.

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

🔥 Рекомендую к просмотру!

🧩 Разберём сегодня небольшую задачку:
https://bigfrontend.dev/react/useUpdateEffect

Нужно реализовать кастомный хук `useUpdateEffect`, который работает почти так же, как useEffect,
но не срабатывает при первом рендере.

Вот возможная реализация 👇

import React, { useEffect, useRef } from 'react';

export function useUpdateEffect(effect: EffectCallback, deps?: DependencyList) {
  const isFirst = useRef(true);

  useEffect(() => {
    if (isFirst.current) {
      isFirst.current = false;
      return;
    }
    return effect();
  }, deps);
}

🔗 Your URL Is Your State

Недавно наткнулась на статью:
https://alfy.blog/2025/10/31/your-url-is-your-state.html

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

Хорошо спроектированный URL — это контракт между приложением и пользователем.
Он описывает смысл, сохраняет контекст и делает взаимодействие предсказуемым.

🧭 Когда стоит хранить состояние в URL:
✅ поисковые запросы, фильтры, сортировки, даты, активные вкладки, режимы просмотра
❌ пароли, личные данные, временные состояния, слишком большие объекты

💡 Лучшие практики:
• Делайте параметры читаемыми и последовательными (?theme=dark&page=2)
• Используйте pushState для навигации, replaceState — для мелких обновлений
• Не храните чувствительные данные
• Избегайте чрезмерно длинных или зашифрованных ссылок

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

💡 Давайте решим лёгкую задачку:
https://bigfrontend.dev/typenoscript/implement-Pick-T-K

По моим наблюдениям, многие фронтендеры не всегда до конца знают TypeScript.
Базовые вещи — да 😊, а вот если копнуть чуть глубже, то многие теряются!

---

📘 Условие задачи:

Реализуйте тип MyPick<T, K> самостоятельно.

type Foo = {
  a: string
  b: number
  c: boolean
}

type A = MyPick<Foo, 'a' | 'b'> // { a: string, b: number }
type B = MyPick<Foo, 'c'>       // { c: boolean }
type C = MyPick<Foo, 'd'>       // Ошибка

Использовать встроенный Pick<T, K> — нельзя 🚫

---

🧠 Чтобы решить задачу, нужно вспомнить две вещи:

1. оператор keyof - https://www.typenoscriptlang.org/docs/handbook/2/keyof-types.html
2. наследование с помощью extends

Тип MyPick принимает:

* первый аргумент — исходный тип T
* второй — K, который может быть только ключом из T

---

✅ Решение:

type MyPick<T, K extends keyof T> = {
  [P in K]: T[P]
}

Так мы получаем новый тип, содержащий только нужные ключи и их типы 👌

🚀 Вышел Storybook 10!

Крупный релиз популярного инструмента для разработки и документирования UI-компонентов.
Главное изменение — переход Storybook на формат ECMAScript Modules (ESM-only).
Это делает проект современнее, ускоряет установку и уменьшает вес зависимостей,
но требует внимания при обновлении — это breaking change.
🧭 Гайд по миграции: https://storybook.js.org/docs/releases/migration-guide-from-older-version

📘 Подробнее о релизе и всех нововведениях:
https://storybook.js.org/releases/10.0

P.S. я уже как-то писала о том

В чём же разница между CommonJS и ES Modules? - https://news.1rj.ru/str/frontenddevelopernews/4
Как вообще уживаются вместе .cjs, .mjs и .js файлы в одном проекте? - https://news.1rj.ru/str/frontenddevelopernews/5

🌟 Site of the Day — Nov 10, 2025
https://www.awwwards.com/sites/messenger

💬 Представляю вам сайт дня — Messenger от студии Abeto.

🔗 Ссылка на сам сайт:
https://messenger.abeto.co/

💡 Недавно наткнулась на очень полезную статью про 10 недооценённых фич JavaScript

и вот что я там обнаружила 👇

1️⃣ Использование Set для удаления дубликатов и быстрых проверок.
2️⃣ Методы Object.entries() и Object.fromEntries() для преобразования объектов.
3️⃣ Операторы ?? (nullish coalescing) и ??= — более безопасные дефолты по сравнению с ||.
4️⃣ Интернационализация через Intl — форматирование чисел, валют, дат.
5️⃣ IntersectionObserver для ленивой загрузки изображений и бесконечной прокрутки.
6️⃣ Promise.allSettled() для обработки набора промисов, когда нужно дождаться всех, даже если некоторые завершились с ошибкой.
7️⃣ Метод Element.closest() для надёжного поиска в DOM вверх по дереву.
8️⃣ Классы URL и URLSearchParams — работа с URL без регулярных выражений.
9️⃣ Цикл for…of — итерации с поддержкой итераторов и возможностью прерывания.
🔟 Топ-уровневый await (top-level await) — позволяет работать с асинхронным кодом в модулях без обёрток.

📖 Подробнее читай в статье:
👉 https://jsdev.space/underrated-js-features/

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

Когда я наткнулась на статью «Ultimate Prompts for Every Developer», сразу стало интересно: "какие там такие промпты, которые действительно полезны в работе?"

Собрала для вас короткую подборку самых практичных — их можно просто копировать и использовать при необходимости 👇

---

1️⃣ Фреймворк для рефакторинга и оптимизации

I have a [language] function in a [framework] project that needs refactoring.

Current code:
[paste code]

Issues I'd like to address:
[specific issue, e.g., low readability]
[specific issue, e.g., non-optimal O(n^2) time complexity]

What I've considered:
[ideas you've already tried]

Constraints:
[must remain backward compatible, no new dependencies]

Please suggest refactored code with explanations,
including trade-offs and potential edge cases.

2️⃣ Code Review от трёх «персон»

Please review this code from three different perspectives:

1. Security specialist:
   - Identify vulnerabilities / injection risks
   - Mention any OWASP Top 10 concerns

2. Performance engineer:
   - Highlight inefficiencies or bottlenecks
   - Suggest better data structures or algorithms

3. Maintainability expert:
   - Point out unclear naming / complex logic
   - Suggest improvements for testability and structure

CONTEXT:
- Tech stack: [React/Node/TS]
- Constraints: [e.g., no new dependencies]

CODE:
[YOUR CODE]

3️⃣ Постепенное проектирование API

I'm designing a RESTful API for a [SPECIFIC DOMAIN] system.
Let's develop this progressively:

STAGE 1: Core resources
- Define resources + relationships
- Primary attributes
- Basic CRUD

STAGE 2: Interaction patterns
- Non-CRUD endpoints
- Filtering, sorting, pagination

STAGE 3: Advanced
- Auth & permissions
- Rate limiting
- Versioning
- Caching (ETag, directives)
- Error format standardization

STAGE 4: Documentation
- Generate OpenAPI spec
- Provide request/response examples

4️⃣ Документация по компоненту/модулю

Generate comprehensive developer documentation for this [FUNCTION/COMPONENT/MODULE]:

[YOUR CODE]

Structure the documentation as follows:

1. OVERVIEW
   - Purpose, functionality, when to use

2. TECH SPECS
   - API, params, return values, types
   - State management (if applicable)
   - Events

3. EXAMPLES
   - Basic example
   - Advanced usage
   - Customization cases

4. TROUBLESHOOTING
   - Common errors
   - Debugging tips
   - Performance considerations

5. RELATED COMPONENTS
   - Dependencies
   - Components frequently used together

---

Полный список из 11 промптов — по ссылке 👇
https://medium.com/@onix_react/ultimate-prompts-for-every-developer-031a6d26a569

Всем привет! 👋

Работая почти 10 лет в разработке, всё чаще замечаю, что многие фронтендеры приходят в профессию без формального IT-образования. Недавно наткнулась на статью, где автор — тоже без классического CS-бэкграунда — делится принципами, которые помогают ему принимать правильные решения «здесь и сейчас».

Мне, человеку с бакалавриатом и магистратурой, было особенно интересно почитать, что же он там написал 🙂

---

🧩 Про «умные» принципы, которые иногда только мешают

Автор пишет, что популярные советы вроде
YAGNI (You Aren’t Gonna Need It),
DRY (Don’t Repeat Yourself)
и «преждевременная оптимизация — корень всех зол»
звучат умно, но в реальной жизни часто создают больше путаницы.

И вот принцип, который действительно помогает ему в работе — правило трёх.

---

📌 Правило трёх

Рефакторить или оптимизировать код стоит только после того, как вы написали его три раза:

1️⃣ Первый раз — просто пишете код, который делает только то, что нужно.
2️⃣ Второй раз — появляется та же логика, и вы буквально копируете её, немного адаптируя.
3️⃣ Третий раз — у вас уже три подобные реализации, и теперь ясно, что обобщать, как упрощать и какой уровень абстракции действительно нужен.

Зачем так делать?
Потому что после трёх повторений вы уже точно знаете:

* что в логике действительно общее,
* что можно упростить,
* какой абстракции хватает,
* и не уйдёте в ненужный оверинжиниринг.

---

⚙️ Принцип «Make it work → Make it right → Make it fast»

Очень хочется оптимизировать всё сразу — но быстрый код часто менее читаемый.

Кент Бек предлагает простой порядок:

🔹 Работает? Если нет — сначала добейтесь этого.
🔹 Делает правильно? Если нет — исправьте логику, входы, поведение.
🔹 Достаточно быстро? Если нет — вот теперь можно оптимизировать.

Смысл простой: нет смысла улучшать код, который пока даже не работает или работает неправильно.

---

✔️ Как итог

Хорошие принципы помогают писать код, который:

* легко читать,
* легко понимать,
* легко изменять,
* легко тестировать.

А плохой код «плох по-разному»: слишком много ответственности, мешанина уровней абстракций, странные оптимизации, лишняя логика.

---

Ссылка на статью:
https://piccalil.li/blog/programming-principles-for-self-taught-front-end-developers/

Это не было бы так смешно, если бы не было правдой 😄
К сожалению, многие фронты порой настолько зациклены на том, чтобы просто сделать «работающий код», что забывают о «хороших манерах» — например, о том, что не только 200 считается успешным результатом. Есть ещё 201, 204 и другие кейсы ✅

И вообще, помимо привычных 200, 400, 404 и 500, существует множество других статус-кодов, которые могут значительно упростить логику на фронте и сделать API более понятным.

Я уже как-то писала пост с HTTP Code Cheatsheet — можете обратить внимание 👇
https://news.1rj.ru/str/frontenddevelopernews/60

Привет! ✨
Собрала полезные материалы для фронтендеров:

1. https://bespoyasov.ru/front-not-pain/
«Фронтенд — это не больно!» — статьи о том, как фронтендеру работать без стресса: взаимодействовать с дизайнерами, бэкендерами и тестировщиками, бороться с рутиной и выгоранием, организовывать рабочий процесс.

2. https://solidbook.vercel.app/
Подробная книга о принципах SOLID. Помогает разобраться, как строить гибкую, предсказуемую и поддерживаемую архитектуру.

3. https://www.patterns.dev/vanilla/module-pattern/
Большая коллекция популярных паттернов разработки в JavaScript, объяснённых просто и визуально. В том числе модульный паттерн и многие другие.

4. https://refactor-like-a-superhero.vercel.app/ru
Практическое руководство по рефакторингу. Чёткие советы, примеры и техники, которые помогают улучшать код без боли и риска всё сломать.

5. https://www.youtube.com/playlist?list=PLaIuVNKRYUyEoKnY0UwapHPk8fEaREHPA
Подробный видеокурс по Figma. По мне часто фронтендеру не хватает этого навыка даже в базовом виде.