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

Что проверяют

Понимаете ли вы, где на самом деле задаётся порядок списка, и не чините ли на клиенте то, что сломано в запросе. Заодно смотрят, знаете ли вы про оптимистичные обновления и чем сортировка одной страницы отличается от порядка во всём наборе.

Как отвечать

Объясните, откуда берётся сбой. Новый пост оказывается сверху обычно потому, что его вставили локально до ответа сервера через unshift, а сервер потом отдаёт страницу в своём порядке. Второй источник: сортировка по времени из Date.now() на клиенте, при том что у остальных записей метки серверные, а часы у клиента свои.

Как надо:

• порядок задаёт сервер, и обязательно со вторым ключом: created_at desc, id desc. Без него записи с одинаковой меткой встают как попало и меняются местами между запросами;
• страницы берутся по курсору от последней пары ключей, а не по смещению: при вставке нового поста смещения едут, появляются дубли и пропуски;
• оптимистичную запись вставляют тем же компаратором, что и остальные, а после ответа заменяют временную настоящей по идентификатору;
• список рендерится по key={post.id}, сортировка идёт по копии: [...posts].sort(cmp).

Про стабильность можно сказать отдельно: в современных движках sort стабилен по спецификации, так что виноват компаратор с равными ключами, а не сам метод.

Где спотыкаются

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

Второе: мутируют состояние. posts.sort() меняет массив на месте, React сравнивает ту же ссылку и перерисовку может не запустить, а мемоизированные дочерние компоненты изменений не увидят вовсе.

Третье: разбор дат. Строка 2026-09-12 читается как UTC, а 2026-09-12T10:00 без смещения как локальное время, и на границе суток порядок плавает. Надёжнее сравнивать числа, полученные из одного серверного формата.