JavaScript Ready | Программирование

Защищаем состояние от устаревших асинхронных результатов!

Порядок запуска асинхронных операций не определяет порядок их завершения. Если несколько вызовов обновляют одно состояние, более ранний запрос может завершиться позже и перезаписать актуальные данные:
let state;

async function loadUser(id) {
const user = await fetchUser(id);
state = user;
}

loadUser(1);
loadUser(2);

Если fetchUser(1) завершится после fetchUser(2), итоговым значением state станет пользователь 1, хотя последним был запущен loadUser(2).

Когда отмена предыдущей операции невозможна или не требуется, актуальность результата можно контролировать с помощью монотонно увеличивающейся версии:
let state;
let version = 0;

async function loadUser(id) {
const currentVersion = ++version;
const user = await fetchUser(id);

if (currentVersion !== version) {
return;
}

state = user;
}

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

При нескольких асинхронных этапах проверку следует выполнять после каждой границы, после которой выполнение может продолжиться с неактуальными данными:
async function loadUser(id) {
const currentVersion = ++version;

const user = await fetchUser(id);

if (currentVersion !== version) {
return;
}

const permissions = await fetchPermissions(user.id);

if (currentVersion !== version) {
return;
}

state = { user, permissions };
}

Проверка версии не отменяет уже выполняющуюся работу. Она определяет только то, сохраняет ли результат право влиять на текущее состояние:
loadUser(1); // version = 1
loadUser(2); // version = 2

// version = 1 игнорируется
// version = 2 может обновить state

🔥 Такой version token реализует семантику latest invocation wins: завершение асинхронной операции отделяется от актуальности её результата и предотвращает запись устаревших данных.

📣 JS Ready | #практика

Почему forEach() не ждёт async-функцию?

forEach() не учитывает возвращаемое значение callback и не содержит механизма ожидания Promise. Поэтому передача async-callback не меняет модель выполнения метода: forEach() синхронно запускает callback для каждого элемента, не ожидая завершения созданных им асинхронных операций:
const users = [1, 2, 3];

users.forEach(async (id) => {
await saveUser(id);
});

console.log("Готово");

"Готово" будет выведено до завершения saveUser(). Каждый вызов async-callback возвращает Promise, но forEach() эти Promise не ожидает и не собирает.

Если операции должны выполняться последовательно, ожидание необходимо сделать частью самого цикла. Для этого подходит for...of с await:
for (const id of users) {
await saveUser(id);
}

console.log("Готово");

Следующая итерация начнётся только после завершения предыдущей. Такой вариант нужен, когда важен порядок выполнения или операции зависят друг от друга.

Для независимых операций можно сформировать массив Promise и дождаться их через Promise.all():
await Promise.all(
users.map((id) => saveUser(id))
);

console.log("Готово");

Promise.all() успешно выполняется после выполнения всех переданных Promise и отклоняется, если хотя бы один из них завершается с ошибкой. При этом остальные уже запущенные операции автоматически не отменяются.

Есть и важное следствие для обработки ошибок: внешний try...catch вокруг forEach() не перехватит последующее отклонение Promise из async-callback:
try {
users.forEach(async (id) => {
await saveUser(id);
});
} catch (error) {
console.error(error);
}

Для управляемой обработки ошибки необходимо ожидать Promise, представляющий выполнение асинхронных операций:
try {
await Promise.all(
users.map((id) => saveUser(id))
);
} catch (error) {
console.error(error);
}

🔥 Проблема не в async внутри forEach(), а в контракте самого метода: forEach() игнорирует возвращаемое значение callback и не ожидает Promise. Для последовательного выполнения используйте for...of с await, для конкурентного выполнения независимых операций — Promise.all().

📣 JS Ready | #практика

Почему JavaScript может изменить большой ID из API

Числовой идентификатор может быть корректно сформирован на сервере, но изменить значение после преобразования в js Number.

Причина заключается в модели представления чисел: Number соответствует IEEE 754 binary64 и не способен точно представить все целые числа произвольного размера:
const id = 9007199254740993;

console.log(id);

// 9007199254740992

Граница гарантированно точного представления целых чисел определяется константой Number.MAX_SAFE_INTEGER:
console.log(Number.MAX_SAFE_INTEGER);

// 9007199254740991

console.log(
Number.isSafeInteger(9007199254740991)
);

// true

Безопасный диапазон составляет от -(2^53 - 1) до 2^53 - 1. За его пределами проблема заключается не просто в том, что число становится «слишком большим»: соседние математические целые уже не обязаны иметь разные представления в Number. Поэтому два разных исходных значения могут оказаться одним и тем же значением javascript:
const a = 9007199254740992;
const b = 9007199254740993;

console.log(a === b);

// true

Для точных операций с большими целыми в js существует BigInt. Суффикс n создаёт значение непосредственно как BigInt, без промежуточного преобразования в Number:
const id = 9007199254740993n;

console.log(id + 1n);

// 9007199254740994n

С API возникает дополнительная граница — десериализация JSON. Сам JSON может содержать последовательность цифр 9007199254740993 как число, но стандартный JSON.parse() преобразует JSON-число в JavaScript Number.

Если значение находится за пределами безопасного целочисленного диапазона, точность теряется уже во время этого преобразования:
const data = JSON.parse(
'{"id":9007199254740993}'
);

console.log(data.id);

// 9007199254740992

После такого парсинга восстановить исходный ID по полученному Number в общем случае невозможно: информация о первоначальном целом уже потеряна.

Поэтому идентификаторы, над которыми не предполагается арифметика, надёжнее передавать в JSON как строки. Это сохраняет исходную последовательность цифр независимо от числовых ограничений JavaScript-клиента:
const data = JSON.parse(
'{"id":"9007199254740993"}'
);

console.log(data.id);

// "9007199254740993"

Если значение всё же требуется использовать в точных целочисленных вычислениях, строку можно явно преобразовать в BigInt уже после получения ответа API:
const data = JSON.parse(
'{"id":"9007199254740993"}'
);

const id = BigInt(data.id);

console.log(id + 1n);

// 9007199254740994n

🔥 Числовая природа ID не означает, что его следует представлять типом Number. Если идентификатор потенциально превышает Number.MAX_SAFE_INTEGER, его представление становится частью корректности API-контракта: строка сохраняет ID без потерь при передаче, а BigInt подходит там, где действительно требуется точная целочисленная арифметика.

📣 JS Ready | #практика

Почему Array.sort() может создать баг далеко от места сортировки!

С sort() проблема не в самой сортировке, а в скрытой мутации. Вызов выглядит как обычное получение отсортированного результата, хотя одновременно изменяет сам исходный массив:
const scores = [30, 10, 20];

const sorted = scores.sort(
(a, b) => a - b
);

console.log(scores);
// [10, 20, 30]

sort() сортирует массив непосредственно и возвращает ту же ссылку. Поэтому изменение увидит не только код, работающий с sorted, но и любой код, который уже хранит ссылку на исходный массив:
const scores = [30, 10, 20];
const cached = scores;

scores.sort((a, b) => a - b);

console.log(cached);
// [10, 20, 30]

Особенно неприятно это становится на границе функций. По названию getSortedUsers() можно ожидать получение нового результата, но реализация незаметно меняет массив вызывающего кода:
function getSortedUsers(users) {
return users.sort(
(a, b) => a.age - b.age
);
}

В результате функция имеет побочный эффект, который не очевиден из места её вызова. Это уже может затронуть состояние, кэш, мемоизацию или другой код, использующий тот же массив:
const users = getUsers();
const original = users;

getSortedUsers(users);

console.log(original === users);
// true

Классический способ избежать этого — сначала создать новый массив и сортировать уже его. Такой код работает, но копирование приходится выражать отдельной операцией:
const sorted = [...scores].sort(
(a, b) => a - b
);

console.log(scores);
// [30, 10, 20]

toSorted() делает намерение явным: получить новый массив с другим порядком элементов, не изменяя исходный. При этом возвращается уже другая ссылка:
const sorted = scores.toSorted(
(a, b) => a - b
);

console.log(scores);
// [30, 10, 20]

console.log(scores === sorted);
// false

Важно, что копируется именно массив. Объекты внутри него не клонируются, поэтому обе коллекции по-прежнему содержат ссылки на одни и те же объекты:
const users = [
{ name: "Alex", age: 30 },
{ name: "Bob", age: 20 },
];

const sorted = users.toSorted(
(a, b) => a.age - b.age
);

console.log(
sorted[0] === users[1]
);
// true

Поэтому изменение самого объекта будет видно через обе коллекции:
sorted[0].age = 25;

console.log(users[1].age);
// 25

Похожая логика есть у toReversed() и toSpliced(): они позволяют выполнить соответствующую операцию без изменения исходного массива, в отличие от мутирующих reverse() и splice().

🔥 Поэтому выбор между sort() и toSorted() — это не просто вопрос синтаксиса, это выбор контракта операции: изменить существующий массив или получить новый, сохранив исходный. Чем больше у массива потребителей, тем важнее эта разница.

📣 JS Ready | #практика

Получаем только изменённые поля объекта!

При изменении состояния приложения можно сравнить предыдущую и текущую версию объекта, чтобы определить только обновлённые значения. Такой diff позволяет отделить изменившиеся поля от тех, которые остались без изменений, и использовать только актуальные данные для дальнейшей обработки.
const oldUser = {
name: "Alex",
age: 30,
role: "developer"
};

const newUser = {
name: "Alex",
age: 31,
role: "developer"
};

Для получения изменённых полей можно преобразовать объект в массив пар через Object.entries(), отфильтровать только отличающиеся значения и собрать новый объект обратно с помощью Object.fromEntries().
const changes = Object.fromEntries(
Object.entries(newUser)
.filter(([key, value]) =>
!Object.is(value, oldUser[key])
)
);

console.log(changes);

В результате получится объект, содержащий только изменённые поля:
{
age: 31
}

Такой подход применяется при обновлении состояния во frontend-приложениях, работе с формами и подготовке частичных изменений для API через PATCH запросы.

Вместо отправки всей структуры можно передать только те значения, которые действительно были изменены.
const hasChanges =
Object.keys(changes).length > 0;

console.log(hasChanges);

Проверка через количество ключей позволяет определить, были ли изменения вообще. Если объект changes пустой, значит исходное и новое состояние полностью совпадают.

Важно учитывать, что данный способ выполняет только поверхностное сравнение (shallow diff) и проверяет значения первого уровня объекта.
const first = {
profile: {
name: "Alex"
}
};

const second = {
profile: {
name: "Alex"
}
};

console.log(first.profile === second.profile);

// false

Вложенные объекты сравниваются по ссылке, поэтому одинаковая структура внутри разных объектов не делает их равными. Для таких случаев требуется использовать глубокое сравнение (deep comparison) или отдельную логику построения diff.

🔥 Также при реализации реальных обновлений через PATCH нужно отдельно учитывать удаление полей, так как простой shallow diff определяет только добавленные и изменённые значения.

📣 JS Ready | #практика