lemon1964

Один из полезных тестов для App Router это не только searchParams сами по себе, но и их грязные варианты. Например: /goods?q=phone&q=tv.

Один из практических узлов в auth-связке Next.js и Django находится не в login-flow, а в обновлении access token. Пока refresh-механика размазана по страницам, компонентам и сервисам, приложение постепенно теряет предсказуемость. Один запрос обновляет токен, второй работает со старым, третий получает 401, а UI в этот момент еще показывает, что поль…

В Next.js с TypeScript ошибка type is not assignable нередко указывает на более полезную вещь, чем кажется по формулировке. Проблема часто не в несовпадении типов как таковом, а в том, что проект пытается передать в доменную функцию ещё не нормализованное значение.

О back и forward обычно вспоминают слишком поздно. Пока всё тестируется в лоб, интерфейс выглядит нормальным. Но как только пользователь проходит цепочку список -> поиск -> другой фильтр -> карточка -> назад, становится видно, насколько страница вообще держится как система.

Один из самых недооцененных узлов в fullstack-связке Next.js и Django находится в jwt и session callbacks. Именно там часто начинается архитектурная путаница.

В fullstack-проектах на Next.js и Django авторизация часто ломается не из-за библиотек, а из-за архитектуры.

Одна из самых практичных ошибок TypeScript в Next.js это possibly undefined. На неё легко смотреть как на помеху, но в рабочем проекте она обычно указывает на более полезную вещь. Где-то в коде есть значение, которое ещё не прошло нормальную границу проверки, а логика уже пытается обращаться с ним как с надёжным.

Одна из типовых проблем в Next.js с TypeScript - данные вроде типизированы, но архитектура от этого надёжнее не становится. Причина в том, что типы ставятся локально, а не на границах системы.

Когда в Next.js нужен Link, а когда router.push. В App Router это не спор двух инструментов, а обычная архитектурная развилка.

searchParams в Next.js App Router удобны не сами по себе. Их сила в другом, они позволяют сделать URL источником правды для страницы. Это особенно хорошо видно на поиске и фильтрах. В React SPA здесь часто появляются useState, useEffect, ручная синхронизация с URL и странное поведение Back/Forward. В App Router можно идти проще: читать searchParams…

Неделю назад писал здесь, что для MVP часто достаточно одной сильной метрики вместо тяжёлой аналитики. Вынес этот подход в отдельную статью на Хабре: https://habr.com/ru/articles/1013258/

Когда делаешь небольшие MVP, очень легко переусложнить проект раньше времени. Особенно в аналитике.

Можно сразу подключить Яндекс.Метрику, Google Analytics, навесить события, построить воронки, завести отдельную БД под метрики, и в какой-то момент обнаружить, что на инфраструктуру проверки идеи уходит больше сил, чем на саму идею.