#app_router — Public Fediverse posts

Optimistic UI и autosave в Next.js без гонок и ложного сохранено

Optimistic UI и autosave выглядят как естественное улучшение интерфейса. Хочется, чтобы новый элемент появлялся сразу, текст не терялся, статус сохранения успокаивал пользователя, а редактор не дёргался на каждом символе. Но здесь интерфейс начинает врать. Новый проект уже нарисован в списке, хотя сервер его ещё не подтвердил. Статус показывает saved, хотя это был ответ от старого запроса. updatedAt обновился, хотя запись на сервере не прошла. В какой-то момент становится ясно, что скорость интерфейса и правдивость интерфейса это разные вещи. В моем учебном проекте Workbench эта граница показана на двух местах. Первое это optimistic create для inline CRUD. Второе это autosave редактора и отдельное демо с requestId. В обоих случаях задача одна и та же. UI должен быть быстрым, но не должен придумывать серверную истину раньше времени. Иначе вместо отзывчивости получается рассинхрон.

https://habr.com/ru/articles/1059760/

#nextjs #typescript #app_router #optimistic_ui #autosave #server_actions #react #вебразработка

Optimistic UI и autosave в Next.js без гонок и ложного сохранено

Optimistic UI и autosave выглядят как естественное улучшение интерфейса. Хочется, чтобы новый элемент появлялся сразу, текст не терялся, статус сохранения успокаивал пользователя, а редактор не дёргался на каждом символе. Но здесь интерфейс начинает врать. Новый проект уже нарисован в списке, хотя сервер его ещё не подтвердил. Статус показывает saved, хотя это был ответ от старого запроса. updatedAt обновился, хотя запись на сервере не прошла. В какой-то момент становится ясно, что скорость интерфейса и правдивость интерфейса это разные вещи. В моем учебном проекте Workbench эта граница показана на двух местах. Первое это optimistic create для inline CRUD. Второе это autosave редактора и отдельное демо с requestId. В обоих случаях задача одна и та же. UI должен быть быстрым, но не должен придумывать серверную истину раньше времени. Иначе вместо отзывчивости получается рассинхрон.

https://habr.com/ru/articles/1059760/

#nextjs #typescript #app_router #optimistic_ui #autosave #server_actions #react #вебразработка

Optimistic UI и autosave в Next.js без гонок и ложного сохранено

Optimistic UI и autosave выглядят как естественное улучшение интерфейса. Хочется, чтобы новый элемент появлялся сразу, текст не терялся, статус сохранения успокаивал пользователя, а редактор не дёргался на каждом символе. Но здесь интерфейс начинает врать. Новый проект уже нарисован в списке, хотя сервер его ещё не подтвердил. Статус показывает saved, хотя это был ответ от старого запроса. updatedAt обновился, хотя запись на сервере не прошла. В какой-то момент становится ясно, что скорость интерфейса и правдивость интерфейса это разные вещи. В моем учебном проекте Workbench эта граница показана на двух местах. Первое это optimistic create для inline CRUD. Второе это autosave редактора и отдельное демо с requestId. В обоих случаях задача одна и та же. UI должен быть быстрым, но не должен придумывать серверную истину раньше времени. Иначе вместо отзывчивости получается рассинхрон.

https://habr.com/ru/articles/1059760/

#nextjs #typescript #app_router #optimistic_ui #autosave #server_actions #react #вебразработка

Server Actions без ручного API, предсказуемый useActionState для inline CRUD в Next.js

В Next.js формы и inline CRUD довольно быстро упираются в одну и ту же развилку. Можно пойти привычным путём и собрать ручной API: отдельный route handler, fetch из клиента, локальные флаги pending, error, success, плюс своя логика для blur, Enter, Escape и закрытия редактора. На небольшом примере это выглядит терпимо. Но как только в проекте появляются создание, переименование, удаление и несколько inline-форм на одном экране, код начинает расползаться не по бизнес-логике, а по обвязке. Проблема в количестве промежуточных слоёв между формой и записью данных. Отдельный endpoint, отдельный клиентский submit, отдельный формат ответа, отдельные флаги состояния, отдельная синхронизация UI после успеха или ошибки. Для таких сценариев Server Actions в App Router нужны потому, что для форм и inline-редактирования дают более короткую и предсказуемую write-точку. В проекте примере Workbench покажем на создании, переименовании и удалении проектов, секций и заметок. У формы есть action, серверная функция получает FormData, возвращает типизированное состояние, а клиент живёт вокруг одного паттерна: state, formAction, isPending. В результате форма собирается как связанный цикл, а не как набор разрозненных обработчиков.

https://habr.com/ru/articles/1043970/

#nextjs #typescript #app_router #server_actions #useactionstate #react #forms #вебразработка

Формы как контракт в Next.js: Zod, fieldErrors и одинаковые правила на client и server

С формами в Next.js проблема обычно начинается не на уровне кнопки submit. Кнопка как раз почти всегда работает. Настоящая путаница начинается позже, когда форма уже живёт в проекте какое-то время. В одном месте ошибка показывается под полем, в другом только общей строкой сверху. Где-то кнопка блокируется на pending, а где-то можно отправить запрос несколько раз подряд. Клиент считает данные валидными, а сервер отвечает, что правило нарушено. Поле уже зелёное, а сохранение всё равно не прошло. В этот момент становится видно, что форма была собрана как кусок UI, а не как контракт. Используем как примеры паттерны из проекта Workbench. Полезно смотреть на форму не как на набор input и submit, а как на договор между UI, валидацией и местом записи данных. У такого договора есть простая форма - какие данные считаются допустимыми, где и как они проверяются, в каком виде ошибка возвращается в интерфейс, что происходит на pending, когда форма блокируется, что считается успехом, а что общей ошибкой, не привязанной к конкретному полю. Как только форма описывается так, код перестаёт расползаться. И здесь Zod в Next.js даёт не просто удобную схему, а способ удерживать client и server в одном наборе правил.

https://habr.com/ru/articles/1025472/

#nextjs #typescript #app_router #zod #forms #validation #react #вебразработка

TypeScript в Next.js как система контрактов, а не типизация ради типизации

Когда разработчик начинает писать на Next.js с TypeScript, первая реакция часто довольно холодная. Вместо того чтобы двигаться быстрее, он начинает чаще видеть ошибки. Где-то не совпал shape объекта, где-то строка не подходит в более узкий тип, где-то TypeScript напоминает, что значение может быть undefined. На этом месте легко сделать неправильный вывод. Кажется, что TS просто добавляет трение и требует больше служебного кода. Обычно проблема не в TypeScript, а в способе мышления. Если использовать его как набор аннотаций поверх уже написанного кода, пользы действительно немного. Но если смотреть на типы как на систему контрактов между слоями приложения, картина меняется. Особенно в Next.js App Router, где у нас постоянно есть границы server и client, внешний ввод из URL, формы, мутации и разные состояния интерфейса. В этот момент TypeScript перестаёт быть типизацией ради типизации. Он начинает отвечать на более важный вопрос: какие состояния в проекте вообще допустимы, а какие не должны пройти дальше границы. По такой модели я выстроил один из своих проектов Workbench. Не начинать с мысли давайте везде поставим типы, а начинать с мысли где у нас проходит граница, что в неё входит и что из неё может выйти. После этого многие решения в коде становятся почти очевидными.

https://habr.com/ru/articles/1018382/

#nextjs #typescript #app_router #server_components #type_safety #zod #react #вебразработка

Как я устал вручную писать сервис-воркеры и сделал next-pwa-pack, чтобы больше не страдать

Сколько лет уже кто-то говорит: «А можно, чтобы оно работало без интернета и ставилось на домашний экран?» И каждый раз после этой фразы начинается медленный спуск в персональный ад — ты лезешь в документацию по PWA, где всё разваливается на ровном месте, service worker живёт своей жизнью, кеш то работает, то ломается, App Router рушит весь твой кастомный пайплайн, а пользователи сидят на старых версиях, потому что вручную обновлять им, конечно, влом. Словом, если ты когда-то пробовал прикрутить оффлайн-режим к Next.js-проекту, ты наверняка вспоминал всех, кто придумал этот стек. Я — точно. Поэтому, как человек, у которого было слишком много кофе и слишком мало терпения, я сделал единственное разумное: написал свою обёртку. Так и появился next-pwa-pack — дроп-ин пакет, который превращает любой Next.js-проект в полноценное PWA, буквально одной строкой. Да, даже с App Router. Просто заворачиваешь свой layout в PWAProvider, и всё: приложение можно установить, оно кэширует страницы, работает оффлайн, синхронизирует вкладки и даже показывает отладочную панель, чтобы не гадать, сработало ли что-нибудь. Воткнул — и живи дальше. А то: Сервис-воркер? Напиши вручную. Кешировать HTML? Сам придумай как. Синхронизация вкладок? Ну это уже магия, удачи. Обновление кеша после деплоя? Ну ты ж senior, сам справишься. 🤡 И ты сидишь, как идиот, с 300 вкладками про Workbox, cache-first , network-only , костылями из Stack Overflow 2019 года, и потеешь. Если раньше каждый запрос «сделай оффлайн» вызывал у меня флэшбэк на тему next-pwa, неподдерживаемых версий, кривого кеша и плясок с бубном вокруг обновлений — теперь всё это ушло. Я хотел простой setup, который просто работает: предзагрузка, нормальные TTL, понятное обновление и синхронизация. Без фокусов, без багов, без “подожди, сейчас DevTools открою”. Погнали дальше!

https://habr.com/ru/articles/935024/

#nextjs #progressive_web_apps #app_router #serviceworker #reactjs #react

Как я устал вручную писать сервис-воркеры и сделал next-pwa-pack, чтобы больше не страдать

Сколько лет уже кто-то говорит: «А можно, чтобы оно работало без интернета и ставилось на домашний экран?» И каждый раз после этой фразы начинается медленный спуск в персональный ад — ты лезешь в документацию по PWA, где всё разваливается на ровном месте, service worker живёт своей жизнью, кеш то работает, то ломается, App Router рушит весь твой кастомный пайплайн, а пользователи сидят на старых версиях, потому что вручную обновлять им, конечно, влом. Словом, если ты когда-то пробовал прикрутить оффлайн-режим к Next.js-проекту, ты наверняка вспоминал всех, кто придумал этот стек. Я — точно. Поэтому, как человек, у которого было слишком много кофе и слишком мало терпения, я сделал единственное разумное: написал свою обёртку. Так и появился next-pwa-pack — дроп-ин пакет, который превращает любой Next.js-проект в полноценное PWA, буквально одной строкой. Да, даже с App Router. Просто заворачиваешь свой layout в PWAProvider, и всё: приложение можно установить, оно кэширует страницы, работает оффлайн, синхронизирует вкладки и даже показывает отладочную панель, чтобы не гадать, сработало ли что-нибудь. Воткнул — и живи дальше. А то: Сервис-воркер? Напиши вручную. Кешировать HTML? Сам придумай как. Синхронизация вкладок? Ну это уже магия, удачи. Обновление кеша после деплоя? Ну ты ж senior, сам справишься. 🤡 И ты сидишь, как идиот, с 300 вкладками про Workbox, cache-first , network-only , костылями из Stack Overflow 2019 года, и потеешь. Если раньше каждый запрос «сделай оффлайн» вызывал у меня флэшбэк на тему next-pwa, неподдерживаемых версий, кривого кеша и плясок с бубном вокруг обновлений — теперь всё это ушло. Я хотел простой setup, который просто работает: предзагрузка, нормальные TTL, понятное обновление и синхронизация. Без фокусов, без багов, без “подожди, сейчас DevTools открою”. Погнали дальше!

https://habr.com/ru/articles/935024/

#nextjs #progressive_web_apps #app_router #serviceworker #reactjs #react

Как я устал вручную писать сервис-воркеры и сделал next-pwa-pack, чтобы больше не страдать

Сколько лет уже кто-то говорит: «А можно, чтобы оно работало без интернета и ставилось на домашний экран?» И каждый раз после этой фразы начинается медленный спуск в персональный ад — ты лезешь в документацию по PWA, где всё разваливается на ровном месте, service worker живёт своей жизнью, кеш то работает, то ломается, App Router рушит весь твой кастомный пайплайн, а пользователи сидят на старых версиях, потому что вручную обновлять им, конечно, влом. Словом, если ты когда-то пробовал прикрутить оффлайн-режим к Next.js-проекту, ты наверняка вспоминал всех, кто придумал этот стек. Я — точно. Поэтому, как человек, у которого было слишком много кофе и слишком мало терпения, я сделал единственное разумное: написал свою обёртку. Так и появился next-pwa-pack — дроп-ин пакет, который превращает любой Next.js-проект в полноценное PWA, буквально одной строкой. Да, даже с App Router. Просто заворачиваешь свой layout в PWAProvider, и всё: приложение можно установить, оно кэширует страницы, работает оффлайн, синхронизирует вкладки и даже показывает отладочную панель, чтобы не гадать, сработало ли что-нибудь. Воткнул — и живи дальше. А то: Сервис-воркер? Напиши вручную. Кешировать HTML? Сам придумай как. Синхронизация вкладок? Ну это уже магия, удачи. Обновление кеша после деплоя? Ну ты ж senior, сам справишься. 🤡 И ты сидишь, как идиот, с 300 вкладками про Workbox, cache-first , network-only , костылями из Stack Overflow 2019 года, и потеешь. Если раньше каждый запрос «сделай оффлайн» вызывал у меня флэшбэк на тему next-pwa, неподдерживаемых версий, кривого кеша и плясок с бубном вокруг обновлений — теперь всё это ушло. Я хотел простой setup, который просто работает: предзагрузка, нормальные TTL, понятное обновление и синхронизация. Без фокусов, без багов, без “подожди, сейчас DevTools открою”. Погнали дальше!

https://habr.com/ru/articles/935024/

#nextjs #progressive_web_apps #app_router #serviceworker #reactjs #react