home.social

#nextjs — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #nextjs, aggregated by home.social.

  1. Next.js CVSS 8.6. Summary by Prasenjit:

    • affects versions 13.4.13+, 14.x, 15.x, and 16.0.0–16.2.4
    • attackers can access your internal services, cloud credentials, API keys, and admin panels
    • no authentication needed
    • one crafted request is all it takes
    • roughly 79,000 instances are exploitable right now
    • vercel-hosted apps are safe, self-hosted are not

    Fix: upgrade to 15.5.16 or 16.2.5 immediately.

    https://github.com/vercel/next.js/releases/tag/v16.2.6

    #JavaScript #NextJs #CVE

  2. A SaaS landing built around the Command Palette as a conversion surface — not decoration.

    CMDK wired to live state, streaming AI responses, R3F dashboard backdrop running off the main thread. Lighthouse 96 mobile · LCP 1.6s · CLS 0.03.

    Stack: Next.js 15 App Router · Tailwind v4 @Theme · Framer Motion 12 · Vercel AI SDK. Performance budget enforced in CI. Built by GrowthSite Lab.

    #Nextjs #TailwindCSS #SaaS #R3F #WebDev #FediverseDevs

  3. Агрегатор LLM, как выбирать живые free-модели и переживать сбои провайдера

    Если в проекте появляется выбор LLM, почти сразу возникает соблазн сделать это как можно проще. Взять один большой список моделей, показать его в интерфейсе, выбрать первую free-модель по умолчанию и считать задачу закрытой. На короткой дистанции это выглядит рабочим вариантом. На длинной начинает ломаться сразу в нескольких местах. Часть моделей числится бесплатными, но отвечает нестабильно. Часть внезапно исчезает из выдачи провайдера. Часть формально жива, но по качеству ответа годится только для демо. Иногда пользователь выбрал одну модель, а провайдер вернул ошибку. Иногда ответ пришел, но уже от другой модели. Иногда список моделей на фронте устарел, а backend уже живет в другой реальности. То есть проблема тут не в том, как красиво показать список LLM. Проблема в том, как построить агрегатор, который умеет выбирать живые free-модели, переживать сбои провайдера и не врать интерфейсу о том, какая модель реально ответила. В одном из своих проектов эта задача решалась не через бесконечный каталог моделей, а через более жесткий инженерный контур. Backend получает сырой список моделей от провайдера, очищает его, отбирает только подходящие free-варианты, оставляет по одной модели на бренд, отдает этот набор на фронт, а во время реального запроса умеет сделать fallback на модель другого бренда. При этом в ответе возвращается не только текст, но и actual_model , чтобы интерфейс знал, кто реально сгенерировал результат.

    habr.com/ru/articles/1033790/

    #LLM #OpenRouter #Django #Python #Nextjs #TypeScript #RTK_Query #AI #API #Fullstack

  4. Агрегатор LLM, как выбирать живые free-модели и переживать сбои провайдера

    Если в проекте появляется выбор LLM, почти сразу возникает соблазн сделать это как можно проще. Взять один большой список моделей, показать его в интерфейсе, выбрать первую free-модель по умолчанию и считать задачу закрытой. На короткой дистанции это выглядит рабочим вариантом. На длинной начинает ломаться сразу в нескольких местах. Часть моделей числится бесплатными, но отвечает нестабильно. Часть внезапно исчезает из выдачи провайдера. Часть формально жива, но по качеству ответа годится только для демо. Иногда пользователь выбрал одну модель, а провайдер вернул ошибку. Иногда ответ пришел, но уже от другой модели. Иногда список моделей на фронте устарел, а backend уже живет в другой реальности. То есть проблема тут не в том, как красиво показать список LLM. Проблема в том, как построить агрегатор, который умеет выбирать живые free-модели, переживать сбои провайдера и не врать интерфейсу о том, какая модель реально ответила. В одном из своих проектов эта задача решалась не через бесконечный каталог моделей, а через более жесткий инженерный контур. Backend получает сырой список моделей от провайдера, очищает его, отбирает только подходящие free-варианты, оставляет по одной модели на бренд, отдает этот набор на фронт, а во время реального запроса умеет сделать fallback на модель другого бренда. При этом в ответе возвращается не только текст, но и actual_model , чтобы интерфейс знал, кто реально сгенерировал результат.

    habr.com/ru/articles/1033790/

    #LLM #OpenRouter #Django #Python #Nextjs #TypeScript #RTK_Query #AI #API #Fullstack

  5. Маркетинговый сайт без дизайнера: 5 практик с Open Design и Claude Code

    Я попробовал собрать маркетинговый сайт через Claude Design - и быстро упёрся в лимиты токенов и непрозрачность облачного тула. Перешёл на Open Design - open-source альтернативу, которая цепляет твой Claude Code, держит дизайн-систему как DESIGN.md в репозитории и работает локально. Под катом - четыре практики, которые сработали на сайте конференции: design-as-code в git, симлинк дизайнера в код сайта, два markdown-файла под бренд и дизайн токены, и как мы учили автономных агентов делать сайт с помощью нашей дизайн системы

    habr.com/ru/articles/1032924/

    #claude_code #claude #anthropic #open_design #aiагенты #дизайнсистема #designascode #nextjs #tailwind_css #маркетинговый_сайт

  6. Как я собрал интерактивную карту 13 000 исторических событий и научил её определять архетип любого города

    HistoryPrint берёт любой город и говорит, какая часть человеческой истории случилась в его радиусе. ~13 000 событий за 5 000 лет, 12 категорий (войны, революции, пандемии, открытия), скоринг по экспоненциальному убыванию расстояния, и в финале — один из 20 архетипов: «Born in Fire», «Plague Walker», «Heir of Enlightenment». Почитать дальше

    habr.com/ru/articles/1032542/

    #nextjs #mapbox #petпроекты #интерактивная_карта #история #tailwind #vercel

  7. Как я собрал интерактивную карту 13 000 исторических событий и научил её определять архетип любого города

    HistoryPrint берёт любой город и говорит, какая часть человеческой истории случилась в его радиусе. ~13 000 событий за 5 000 лет, 12 категорий (войны, революции, пандемии, открытия), скоринг по экспоненциальному убыванию расстояния, и в финале — один из 20 архетипов: «Born in Fire», «Plague Walker», «Heir of Enlightenment». Почитать дальше

    habr.com/ru/articles/1032542/

    #nextjs #mapbox #petпроекты #интерактивная_карта #история #tailwind #vercel

  8. Hey everyone 👋

    Just joined TechHub.

    Senior Software Engineer focused on:
    → React / Next.js / React Native
    → Node.js / GraphQL
    → Cloud (AWS) + Web3

    I enjoy building scalable products and clean user experiences.

    Currently exploring more in decentralized apps + ownership-driven systems 🔗

    Looking forward to connecting with builders, founders, and engineers here.

    #Mastodon #TechHub #WebDev #JavaScript #React #NextJS #NodeJS #Web3

  9. Дуров стену не вернул, поэтому я написал свою – агрегатор Telegram-каналов на Telethon

    «Дуров, верни стену» – мем старый, но точный. ВКонтакте начала 2010-х была, при всех своих недостатках, одним из последних мест в рунете с по-настоящему живой лентой. Не алгоритмической, не персонализированной до тошноты – просто всё подряд от всех, на кого подписан. Новости соседствовали с мемами, мемы – с чьей-то репостнутой статьёй про квантовую физику, которую ты никогда не дочитаешь, но пролистаешь с удовольствием. Была случайность, была живость, был сам факт того, что ты не знаешь, что увидишь следующим. Потом ВК превратился в то, во что превращается каждая платформа – в алгоритмический прямоугольник, оптимизированный под время на сайте. Мы переехали в Telegram. Telegram честнее: хронологический порядок, никакого умного ранжирования, читаешь то, на что подписался. Но одна вещь так и не появилась – единая лента. В ВК у тебя была стена, куда всё стекалось само. В Telegram двадцать каналов – это двадцать отдельных мест, которые надо обходить руками каждый день. Папки? Пробовал. Папки – это шкаф. Они раскладывают каналы по полочкам, но за каждой полкой всё равно надо открывать каждый ящик отдельно. Единого потока нет. Ботов-агрегаторов в маркете штук пять – все сломаны по одной и той же причине: Bot API физически не видит каналы, в которых бот не является администратором. То есть публичный новостной канал с миллионом подписчиков – недоступен. Бот читает только то, куда его добавили руками, а никто не добавляет чужих ботов в админы своих каналов. Логично, но бесполезно. В какой-то момент я окончательно устал и собрал своё.

    habr.com/ru/articles/1030702/

    #telegram #telethon #mtproto #rss #selfhosted #fastapi #nextjs #open_source #агрегатор

  10. Optimización de Suites de Automa…

    El caching es una técnica que permite almacenar datos temporales para acelerar procesos. En el contexto de la automatización, esto significa que los resultados de tareas previas se guardan para evitar cálculos redundantes.

    norvik.tech/news/optimizacion-

    #Technology #Caching #Automatizacion #DesarrolloWeb #Nextjs #NorvikTech #DesarrolloSoftware #TechInnovation

  11. Кэширование в Next.js App Router, как увидеть, почему данные не обновились

    С кэшированием в Next.js обычно случается одна и та же история. API уже отдаёт новые данные, страница открывается заново, а на экране всё ещё старая версия. После этого в код быстро добавляют cache: "no-store" , данные начинают запрашиваться на каждый заход, и через пару минут появляется уже другой вопрос - зачем тогда вообще нужен встроенный механизм кэширования. Проблема в том, что кэширование обычно звучит как одно явление, а на практике в App Router похожие ощущения могут давать разные уровни поведения. Навигация назад и вперёд может переиспользовать клиентский кэш маршрута, сам маршрут может рендериться по-разному, а серверный fetch в Next.js имеет собственные стратегии кэширования и перевалидации. В актуальной документации это уже разделено на новый режим с Cache Components и на прежнюю модель без них. В этой статье речь именно о привычной модели App Router без Cache Components, где поведение обычно задаётся через fetch , cache , next.revalidate и route segment config. ( Next.js ) Полезнее всего разбирать такую тему не с теории, а с наблюдения. Не с вопроса как устроены все слои кэша в Next.js, а с вопроса почему на одном и том же маршруте иногда обновляется рендер страницы, а иногда обновляются данные, и это не всегда одно и то же. Для примеров ниже используется проект Goods Finder и внешний API DummyJSON. Идея - сначала добавить на страницу штамп серверного рендера, потом отдельно показать момент получения данных, а уже после этого сравнить force-cache , no-store и revalidate .

    habr.com/ru/articles/1030134/

    #nextjs #app_router #caching #revalidate #nostore #forcecache #server_components #react #javascript #вебразработка

  12. Как ощущаются 70к строк TS для гетеросексуала Go — потратить год жизни в 18

    Сегодня я хочу рассказать про то, как гетеросексуальный бэкендер (до этого момента коим я себя в той или иной степени считал) переживает болезненный опыт построения клиентской части платформы. Ради интереса недавно я посмотрел, сколько примерно строк на данный момент насчитывает репозиторий фронтенда Kroncl (название платформы), и приятно удивился числу 70. Сделаю поправку на то, что очевидно: объём кода не свидетельствует о его чистоте и виртуозном ведении (опытные читатели скорее установят обратную зависимость).

    habr.com/ru/articles/1029412/

    #frontend #frontend_разработка #nextjs #ts #go #golang #ой

  13. Как ощущаются 70к строк TS для гетеросексуала Go — потратить год жизни в 18

    Сегодня я хочу рассказать про то, как гетеросексуальный бэкендер (до этого момента коим я себя в той или иной степени считал) переживает болезненный опыт построения клиентской части платформы. Ради интереса недавно я посмотрел, сколько примерно строк на данный момент насчитывает репозиторий фронтенда Kroncl (название платформы), и приятно удивился числу 70. Сделаю поправку на то, что очевидно: объём кода не свидетельствует о его чистоте и виртуозном ведении (опытные читатели скорее установят обратную зависимость).

    habr.com/ru/articles/1029412/

    #frontend #frontend_разработка #nextjs #ts #go #golang #ой

  14. Как ощущаются 70к строк TS для гетеросексуала Go — потратить год жизни в 18

    Сегодня я хочу рассказать про то, как гетеросексуальный бэкендер (до этого момента коим я себя в той или иной степени считал) переживает болезненный опыт построения клиентской части платформы. Ради интереса недавно я посмотрел, сколько примерно строк на данный момент насчитывает репозиторий фронтенда Kroncl (название платформы), и приятно удивился числу 70. Сделаю поправку на то, что очевидно: объём кода не свидетельствует о его чистоте и виртуозном ведении (опытные читатели скорее установят обратную зависимость).

    habr.com/ru/articles/1029412/

    #frontend #frontend_разработка #nextjs #ts #go #golang #ой

  15. Вся ваша жизнь помещается в 4000 клеток. Добавим GitHub‑коммиты, среднюю продолжительность жизни и 21 фактор смертности

    Всем привет! У человека в среднем около 4000 недель жизни. Четыре тысячи. Если нарисовать каждую неделю как маленькую клеточку — вся ваша жизнь поместится на один экран. Вот прям вся. От рождения до смерти. Мне 37 — значит примерно 1900 клеток уже закрашены, а оставшиеся… ну, это мы ещё посчитаем. Эта концепция не моя и не новая — но на днях она всплыла в одном бизнес‑чате. Товарищ скинул скриншот из бота который как раз рисует такой grid. Закрашивает прожитые недели, оставляет пустые те что впереди. Красиво, минималистично, грустно. И я спросил: «А тебя это не тревожит?»

    habr.com/ru/articles/1020610/

    #github #life_in_weeks #визуализация_жизни #open_source #nextjs #petproject #contribution_graph #life_expectancy #здоровье #продолжительность_жизни

  16. Как я построил кеш страниц для многодоменного проекта с помощью PVC и кастомного подхода

    У меня был проект, где один Next.js сайт обслуживал несколько доменов, и возникла задача — эффективно кешировать страницы, чтобы не пересоздавать их каждый раз. Сначала я попробовал внедрить кеширование через Redis: я написал хендлер, подключил его, но вскоре обнаружил, что Redis потребляет колоссальный объём оперативной памяти — порядка 100 ГБ, и это при том, что ещё не все запросы были закешированы. Тогда я решил поискать другой подход и обратил внимание на PVC — общее хранилище, которое могли бы использовать все поды. Я начал изучать варианты работы с PVC и довольно быстро пришёл к идее общего кеш‑хранилища для всех подов. Я попробовал просто писать данные в PVC, но столкнулся с проблемой: каждый раз, когда под поднимался, он перезаписывал кеш. До тех пор, пока не подняты все поды, данные постоянно перезаписывались, а мне нужно было, чтобы первый под записал данные, а последующие только читали их. Я начал искать, как сделать кастомный кеш‑хендлер, но готовых решений не нашёл.

    habr.com/ru/articles/1028314/

    #pvc #nextjs #redis #cache #next #node

  17. We're supporting @sage_southaus to do undertake a particiaptory micro-grant funding round for local grassroots groups and initiatives that can offer projects to help address systemic and long term issues around wellbeing in our activist (and related) communities.

    We're preparing to use an incredible open source tool called CoBudget but as we look over the code we can see that since COVID the project could do with a little love.

    Are you or do you know any devs who could look over the project code and pass on their thoughts for improving the developer experience on the project.

    The project needs to attract some new devs and we've often found making it easier to get involved and contribute can help attract new dev contributors.

    github.com/cobudget/cobudget/

    Tech Stack:

    #NextJs #Typescript #Urql #CoBudget #ApolloGraphQl #Prisma #PostgreSQL

    #dev #OpenSource #Enspiral #CoBudget

  18. Пять неочевидных вещей, которые я узнал, запуская кино-соцсеть: от robots.txt-ловушки до 24-мерной математики вкуса

    Последние полгода я работаю над VibeMuvik — кино-соцсетью с рецензиями, дебатами и синхронным просмотром фильмов. Одна из тех штук, которые «ну вроде несложно», пока не начинаешь копать. Эта статья — про неожиданные находки . Не про «как я выбрал стек» (скучно) и не про «туториал по WebRTC» (и без меня есть). Это пять ситуаций, в которых я споткнулся, обнаружил что-то интересное, и подумал «об этом стоит рассказать — другим пригодится». Поехали.

    habr.com/ru/articles/1027876/

    #robotstxt #SEO #WebRTC #Nextjs #IndexNow #sitemap #Googlebot #Cinema_DNA #синхронный_просмотр #рекомендательные_системы

  19. Тренд на деградацию: как я написал прокси-шакализатор на Next.js, чтобы помочь замедлить интернет

    Современные проблемы требуют современных решений. Когда важные люди в высоких кабинетах планомерно замедляют привычные сервисы, режут трафик и заставляют глобальную сеть работать со скоростью уставшего почтового голубя, у любого нормального инженера рано или поздно сдают нервы. Смотреть на то, как твой вылизанный бандл грузится рывками из-за отваливающихся узлов связи, больше нет сил. Все эти бесконечные битвы за 100/100 в Google PageSpeed, микро-оптимизации LCP и внедрение Edge-кэширования теряют смысл, когда пакеты просто не доходят до адресата. И в какой-то момент я осознал простую истину: если ты не можешь остановить глобальную деградацию веба — возглавь её. Раз уж мы летим в прошлое, давайте лететь туда с ветерком. Под скрежет диалап-модема, с вырвиглазными GIF-баннерами, кислотными фонами и ломающейся вёрсткой. Встречайте: Шакализатор сайтов 3000 . Обшакалиться

    habr.com/ru/articles/1027376/

    #nextjs #cheerio #парсинг #web_10 #деградация #ретровэб #sharp

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

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

    habr.com/ru/articles/1025472/

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

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

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

    habr.com/ru/articles/1025472/

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

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

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

    habr.com/ru/articles/1025472/

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

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

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

    habr.com/ru/articles/1025472/

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

  24. Как я перестал копипастить один пост в три соцсети и сделал свой канал наконец видимым для Яндекс и Google

    В этой статье я расскажу, с какими болями я столкнулся при блокировки телеграмм и как в итоге закрыл их проектом, который сам же себе и сделал. Если Вы ведёте канал в телеграмм — возможно, пригодится. Простой и бесплатный кросспостинг из телеграмм в VK и MAX.

    habr.com/ru/articles/1025064/

    #Telegram_канал #SEO_для_Telegram #индексация_Telegram #кросспостинг #автоматизация_контента #Flask #Nextjs #Telegram_Bot_API #видимость_канала

  25. Почему ваш бандл тяжелее чем должен быть — тестирую tree shaking на 7 бандлерах

    Вы уверены, что ваш бандлер вырезает неиспользуемый код? Я тоже был уверен — пока бандл Next.js проекта не оказался в два раза тяжелее, чем нужно. Прогнал одинаковый тест на webpack, rollup, vite, esbuild и Next.js — 5 из 7 ломаются на банальном barrel файле. Полез в исходники, нашёл основную причину — и она оказалась не там, где ожидал.

    habr.com/ru/articles/1024404/

    #tree_shaking #webpack #barrel_file #bundler #nextjs #rollup #vite #esbuild #оптимизация_бандла #фронтенд

  26. Нормализация состояния в React через реестр сущностей: паттерн на Zustand с рекурсивным парсингом и мягкими удалениями

    В этой статье я разберу паттерн Entity Registry — плоский реестр сущностей на базе Zustand, который автоматически нормализует любые ответы API, хранит данные в едином словаре по ID и обеспечивает точечный ре-рендер только тех компонентов, чьи данные действительно изменились. Отдельно разберём трюк с enumerable: false для мягких удалений — пожалуй, самую изящную часть паттерна.

    habr.com/ru/articles/1019110/

    #React #Nextjs #TypeScript #JavaScript #Vovkts #Zustand #Redux #нормализация

  27. Нормализация состояния в React через реестр сущностей: паттерн на Zustand с рекурсивным парсингом и мягкими удалениями

    В этой статье я разберу паттерн Entity Registry — плоский реестр сущностей на базе Zustand, который автоматически нормализует любые ответы API, хранит данные в едином словаре по ID и обеспечивает точечный ре-рендер только тех компонентов, чьи данные действительно изменились. Отдельно разберём трюк с enumerable: false для мягких удалений — пожалуй, самую изящную часть паттерна.

    habr.com/ru/articles/1019110/

    #React #Nextjs #TypeScript #JavaScript #Vovkts #Zustand #Redux #нормализация

  28. Нормализация состояния в React через реестр сущностей: паттерн на Zustand с рекурсивным парсингом и мягкими удалениями

    В этой статье я разберу паттерн Entity Registry — плоский реестр сущностей на базе Zustand, который автоматически нормализует любые ответы API, хранит данные в едином словаре по ID и обеспечивает точечный ре-рендер только тех компонентов, чьи данные действительно изменились. Отдельно разберём трюк с enumerable: false для мягких удалений — пожалуй, самую изящную часть паттерна.

    habr.com/ru/articles/1019110/

    #React #Nextjs #TypeScript #JavaScript #Vovkts #Zustand #Redux #нормализация

  29. Нормализация состояния в React через реестр сущностей: паттерн на Zustand с рекурсивным парсингом и мягкими удалениями

    В этой статье я разберу паттерн Entity Registry — плоский реестр сущностей на базе Zustand, который автоматически нормализует любые ответы API, хранит данные в едином словаре по ID и обеспечивает точечный ре-рендер только тех компонентов, чьи данные действительно изменились. Отдельно разберём трюк с enumerable: false для мягких удалений — пожалуй, самую изящную часть паттерна.

    habr.com/ru/articles/1019110/

    #React #Nextjs #TypeScript #JavaScript #Vovkts #Zustand #Redux #нормализация

  30. [Перевод] Основные элементы экосистемы JavaScript по состоянию на 2026 год

    Ранее мы писали похожие статьи о CSS , но JavaScript заслуживает не меньшего внимания! Тем более что JavaScript лучше справляется с версионированием. Мы рассмотрим новые возможности самого языка, а также основные среды выполнения, фреймворки, библиотеки и инструменты.

    habr.com/ru/articles/1021182/

    #javascript #js #typescript #ts #nodejs #npm #vite #ecmascript #nextjs #react

  31. [Перевод] Основные элементы экосистемы JavaScript по состоянию на 2026 год

    Ранее мы писали похожие статьи о CSS , но JavaScript заслуживает не меньшего внимания! Тем более что JavaScript лучше справляется с версионированием. Мы рассмотрим новые возможности самого языка, а также основные среды выполнения, фреймворки, библиотеки и инструменты.

    habr.com/ru/articles/1021182/

    #javascript #js #typescript #ts #nodejs #npm #vite #ecmascript #nextjs #react

  32. [Перевод] Основные элементы экосистемы JavaScript по состоянию на 2026 год

    Ранее мы писали похожие статьи о CSS , но JavaScript заслуживает не меньшего внимания! Тем более что JavaScript лучше справляется с версионированием. Мы рассмотрим новые возможности самого языка, а также основные среды выполнения, фреймворки, библиотеки и инструменты.

    habr.com/ru/articles/1021182/

    #javascript #js #typescript #ts #nodejs #npm #vite #ecmascript #nextjs #react