Журнал: имена и номера рождаются на телефоне

Подход в «Подходе» — не отдельная запись: у него есть поле workoutId, ссылка на тренировку. Тренировку человек создаёт прямо в зале — «Ноги, 11 сентября» — и тут же записывает в неё первый подход. Если номера выдаёт сервер, как у addSet в заглушке из прошлой статьи, то у тренировки нет номера, пока сервер не ответил. А сервер не ответит до выхода из зала, и подходу не на что сослаться.

Обходной путь известен — временный id. Тренировка живёт как tmp-1, а когда сервер ответит «417», приложение переписывает tmp-1 на 417 везде, где он успел оказаться: в workoutId каждого подхода, в операциях, которые ждут отправки, в адресе /workout/tmp-1 в истории стека из главы про навигацию, в ключе строки списка. Последнее видно глазами: keyExtractor из статьи про FlatList вернёт другой ключ, React сочтёт строку новой и смонтирует её заново, сбросив её состояние, — механизм разобран в «Своей сверке» части IV. Любое пропущенное место остаётся ссылкой в никуда. А если ответ сервера потеряется по дороге, повтор создаст тренировку второй раз — этот случай разберёт глава 7.

Проще, чтобы имя строки рождалось там же, где строка: на телефоне, в момент нажатия. Тогда подход ссылается на тренировку сразу, и ссылка остаётся верной навсегда — после синхронизации id тот же, переписывать нечего. Первое, что приходит в голову, — свой счётчик: 1, 2, 3. Проверим его на двух устройствах: телефон в зале без сети и веб-версия дома создают по тренировке, а потом копии сходятся, и строка с тем же id считается той же самой строкой. Второй прогон — тот же, но к номеру приписано имя устройства. Прогноз: что останется после слияния в каждом прогоне?

type Row = { id: string; title: string };

// копия дневника на одном устройстве: имя новой строке даёт само устройство
function createDevice(prefix: string) {
  let n = 0;
  const rows = new Map<string, Row>();
  return {
    rows,
    create(title: string) {
      n += 1;
      rows.set(prefix + n, { id: prefix + n, title });
    },
  };
}

// так сходятся копии: строка с тем же id — та же самая строка
function merge(...devices: ReturnType<typeof createDevice>[]) {
  const all = new Map<string, Row>();
  devices.forEach((device) => device.rows.forEach((row) => all.set(row.id, row)));
  return [...all.values()].map((row) => row.id + " " + row.title).join(" | ");
}

// телефон в зале без сети, веб-версия дома; синхронизации между ними ещё не было
const phone = createDevice("");
const web = createDevice("");
phone.create("ноги");
web.create("спина");
console.log("просто счётчик:", merge(phone, web));

const phoneA = createDevice("A-");
const webB = createDevice("B-");
phoneA.create("ноги");
webB.create("спина");
console.log("устройство + счётчик:", merge(phoneA, webB));

Простой счётчик выдал обоим устройствам «1», и при слиянии «спина» с веба затёрла «ноги» с телефона: тренировка пропала целиком. Хуже того, подходы телефона ссылались на тренировку «1» и теперь молча висят на «спине» — ошибки нет, данные просто неверны. Имя должно быть уникальным не на устройстве, а везде. Приставка устройства делает его таким: счётчики A и B могут совпадать сколько угодно, а «A-1» и «B-1» не совпадут никогда. Условие одно — у двух устройств не бывает одной приставки.

Имя строки рождается там же, где строка. Всё остальное — переписывание ссылок задним числом.

«A» и «B» в примерах — ради читаемости. Настоящая приставка должна быть уникальной среди всех устройств всех пользователей, а договориться об этом не с кем: сети нет. Поэтому имя устройства — случайное число такой длины, что совпадения на практике не бывает: UUID версии 4, 122 случайных бита. Создаётся оно один раз, при первом запуске, и дальше хранится рядом с журналом. В браузере для этого есть crypto.randomUUID(). Прогноз: что скажет компилятор и что напечатает пример?

// имя устройства создаётся один раз, при первом запуске; тысяча здесь — проверить, не совпадут ли
const ids = Array.from({ length: 1000 }, () => crypto.randomUUID());

// сами id не печатаем: они новые при каждом запуске
console.log("randomUUID:", ids[0].length, "символов");
console.log("уникальных:", new Set(ids).size, "из", ids.length);
console.log("версия:", [...new Set(ids.map((id: string) => id[14]))].join(", "));

Компилятор пишет «Не удается найти имя "crypto".», а пример всё равно выполняется: тысяча id по 36 символов, все разные. Правы оба, и в этом весь смысл примера. Выполняет код браузер — песочница учебника, а в браузере crypto есть. Проверяет же компилятор по типам набора rn, где нет библиотеки DOM, — и глобального crypto там нет по той же причине, по какой его нет на телефоне. React Native 0.86 при старте ставит свои глобали — fetch, XMLHttpRequest, FormData, URL, Blob, WebSocket, AbortController (Libraries/Core/setUpXHR.js). Expo SDK 57 добавляет TextDecoder, structuredClone и свой fetch (expo/src/winter/runtime.native.ts). crypto нет ни в одном из списков, и на телефоне та же строка упадёт с ReferenceError.

Это обратная сторона ловушки из статьи «Что в этой песочнице настоящее». Там типы были шире рантайма предпросмотра: PermissionsAndroid компилировался и падал. Здесь наоборот — рантайм предпросмотра шире телефона, и правду о телефоне говорит компилятор. Пример печатает длину и число уникальных, а не сами id: они новые при каждом запуске, и сверять вывод было бы не с чем. Цифра 4 на пятнадцатой позиции — номер версии UUID; у четвёртой версии всё, кроме нескольких служебных бит, случайно.

На телефоне тот же UUID даёт randomUUID() из пакета expo-crypto. Ставится он как любой модуль Expo, а в коде меняется только импорт:

npx expo install expo-crypto

// shared/device-id.ts в проекте на телефоне
import { randomUUID } from "expo-crypto";

// один раз, при первом запуске: дальше имя устройства хранится вместе с журналом
export function createDeviceId(): string {
  return randomUUID();
}

Внутри пакета — две вещи, знакомые по статье «Одно приложение, три платформы». randomUUID зовёт нативный модуль ExpoCrypto через requireNativeModule — так же в той статье ExpoSecureStore.ts доставал из реестра свой модуль. Как этот реестр устроен на телефоне, разберёт статья «Модуль — это запись в реестре» в главе 9. А рядом лежит ExpoCrypto.web.js — файл того же модуля для веба, который сборщик выбирает по суффиксу платформы. Веб-версия берёт тот самый globalThis.crypto, что сработал в песочнице:

// expo-crypto 57.0.3, build/Crypto.js — то, что вы импортируете; сокращено
import ExpoCrypto from './ExpoCrypto';
export function randomUUID() {
    return ExpoCrypto.randomUUID();
}

// build/ExpoCrypto.js — на телефоне: запись из реестра нативных модулей
export default requireNativeModule('ExpoCrypto');

// build/ExpoCrypto.web.js — в вебе: WebCrypto браузера; сокращено
const getCrypto = () => {
    if (typeof globalThis.crypto !== 'undefined') {
        return globalThis.crypto;
    }
    // …
};
export default {
    // …
    randomUUID() {
        return getCrypto().randomUUID();
    },
};

Пакеты Expo в песочнице не собираются — expo-modules-core тянет TurboModuleRegistry, которого нет в react-native-web, — поэтому expo-crypto здесь только листинг, а примеры дальше обходятся приставками A и B. Можно было бы давать randomUUID() каждой строке и обойтись без счётчика вовсе — многие приложения так и делают: хранить счётчик не нужно, цена — 36 символов в каждом имени и в каждой ссылке. Устройство + счётчик короче и читается глазами — «A-3», — но обязывает хранить счётчик так же надёжно, как журнал: иначе после перезапуска счёт начнётся с единицы и имена повторятся (задача 1). В песочнице же годится только счётчик, потому что эталон вывода не должен плавать.

// id, упорядоченный по времени, как у UUID v7 и ULID: впереди 48 бит показаний часов
function timeId(clockMs: number, device: string) {
  return clockMs.toString(16).padStart(12, "0") + "-" + device;
}

const tenAm = Date.UTC(2026, 8, 11, 7, 0); // 10:00 по Москве
const minute = 60_000;
// A записал подход в 10:00, B — в 10:02, но часы телефона B отстают на пять минут
const fromA = timeId(tenAm, "A");
const fromB = timeId(tenAm + 2 * minute - 5 * minute, "B");
console.log("первым по id:", [fromA, fromB].sort()[0].slice(-1));

Имена есть; теперь о том, что хранилище помнит. Хранилище из прошлой статьи принимало строку целиком и забывало, какой она была. Экрану этого хватает, синхронизации — нет: серверу надо отправить не «вот весь дневник», а «вот что изменилось с прошлого раза», и отправить так, чтобы правки с двух устройств можно было свести. Поэтому каждое изменение становится операцией из четырёх полей:

Хранилище из прошлой статьи — в подложке, журнал пишется поверх него: операция ложится в журнал, а её результат — в хранилище, чтобы экраны, подписанные через useSyncExternalStore, узнали о записи как раньше. Имена строк выдаёт сам журнал. Сценарий: создать тренировку, записать в неё подход и поправить вес. Прогноз: какие строки журнала напечатаются и совпадёт ли свёртка журнала с тем, что лежит в хранилище?

type Fields = Record<string, string | number>;
type Row = Fields & { id: string };
type Op = { opId: string; rowId: string; fields: Fields; at: number };
interface Store {
  write(row: Row): void;
  get(id: string): Row | undefined;
  list(): Row[];
}
declare function createStore(): Store;
declare function now(): number;

// строка — все её операции, наложенные по порядку
const apply = (row: Row | undefined, op: Op): Row => ({ id: op.rowId, ...row, ...op.fields });
const fold = (log: Op[]) =>
  log.reduce((rows, op) => rows.set(op.rowId, apply(rows.get(op.rowId), op)), new Map<string, Row>());

function createJournal(device: string, store: Store) {
  let rowSeq = 0;
  let opSeq = 0;
  const log: Op[] = [];
  return {
    newId: () => device + "-" + ++rowSeq,
    change(rowId: string, fields: Fields) {
      const op = { opId: device + ":" + ++opSeq, rowId, fields, at: now() };
      log.push(op);
      store.write(apply(store.get(rowId), op));
    },
    // пока сервера нет, не отправлено ничего: вся очередь — будущая пачка главы 7
    outbox: () => [...log],
  };
}

const store = createStore();
const journal = createJournal("A", store);
const legs = journal.newId();
journal.change(legs, { title: "ноги" });
const bench = journal.newId();
journal.change(bench, { workoutId: legs, kg: 80, reps: 5 });
journal.change(bench, { kg: 82.5 });

journal.outbox().forEach((op) => console.log(op.opId, op.rowId, JSON.stringify(op.fields)));
console.log("строка " + bench + ":", JSON.stringify(store.get(bench)));
const folded = JSON.stringify([...fold(journal.outbox()).values()]);
console.log("свёртка журнала — те же строки:", folded === JSON.stringify(store.list()));

Строк две, операций три: правка веса — отдельная операция с одним полем kg. Подход A-2 ссылается на тренировку A-1, созданную двумя строками выше, без единого ответа сервера. Строка — это reduce из части I по журналу: apply накладывает поля операции на то, что было, начиная с пустоты. Хранилище держит результат свёртки готовым, чтобы экран не пересчитывал журнал на каждой отрисовке, но правда — журнал. Строки из журнала собираются заново всегда, журнал из строк — никогда: по строке не видно, что вес правили. На этом стоит следующая статья: на диск ляжет журнал, а строки после перезапуска соберёт свёртка.

Неотправленные операции и есть исходящая очередь. Пока сервера нет, не отправлено всё, и outbox отдаёт журнал целиком — это будущая пачка, которую в главе 7 заберёт синхронизация. Из очереди будут уходить операции, на которые сервер вынес вердикт.

Это не оптимистичный ответ из статьи про useOptimistic части IV. Там экран показывал то, чего сервер ещё не подтвердил, и откатывал показанное при ошибке. Здесь запись на телефоне и есть результат: сеть пропала — откатывать нечего, операция просто ждёт в очереди. Что делать, если сервер операцию отвергнет, решает глава 7.

У записи теперь две половины: строка в хранилище и операция в журнале. Экран читает первую, синхронизация отправит вторую, и если между ними случится сбой, половины разойдутся. Очевидный порядок — сначала экран, пусть человек видит подход сразу, потом журнал. Сравним его с записью одним шагом. В песочнице процесс не уронить, поэтому сбой изображает рубильник из подложки: после crash.armed = true ближайший crash.here() бросает ошибку. Стоит он в одном месте — в сборке операции, где на телефоне выдаётся id и читаются часы. Прогноз для обоих порядков: сколько строк и сколько операций останется, если сбой придётся на второй подход?

type Fields = Record<string, string | number>;
type Row = Fields & { id: string };
type Op = { opId: string; rowId: string; fields: Fields; at: number };
interface Store {
  write(row: Row): void;
  get(id: string): Row | undefined;
  list(): Row[];
}
declare function createStore(): Store;
declare function now(): number;
declare function apply(row: Row | undefined, op: Op): Row;
declare const crash: { armed: boolean; here(): void };

let opSeq = 0;
// собрать операцию — выдать id, прочитать часы: на телефоне падать здесь есть чему
function makeOp(rowId: string, fields: Fields): Op {
  crash.here();
  return { opId: "A:" + ++opSeq, rowId, fields, at: now() };
}

// экран сразу, журнал потом
function screenFirst(store: Store, log: Op[], rowId: string, fields: Fields) {
  store.write({ id: rowId, ...store.get(rowId), ...fields });
  log.push(makeOp(rowId, fields));
}

// одним шагом: сначала всё, что может упасть, потом обе записи подряд
function oneStep(store: Store, log: Op[], rowId: string, fields: Fields) {
  const op = makeOp(rowId, fields);
  log.push(op);
  store.write(apply(store.get(rowId), op));
}

const ways = [["экран сразу, журнал потом", screenFirst], ["одним шагом", oneStep]] as const;
for (const [name, change] of ways) {
  const store = createStore();
  const log: Op[] = [];
  change(store, log, "A-1", { kg: 80, reps: 5 });
  crash.armed = true;
  try {
    change(store, log, "A-2", { kg: 82.5, reps: 5 });
  } catch {
    // ошибку поймали — try вокруг обработчика или граница ошибок — и приложение живёт дальше
  }
  console.log(name + ": строк", store.list().length, "| в журнале", log.length);
}

Порядок «экран сразу» оставил две строки и одну операцию. Подход A-2 виден в ленте, и человек уверен, что он записан, — но в очереди его нет, и синхронизация о нём не узнает никогда: он живёт только в памяти этого телефона. Запись одним шагом не оставила от сбоя ничего: строка одна, операция одна. Неудачной записи нет ни на экране, ни в очереди, и человек, увидев ошибку, запишет подход заново. Разница только в порядке: всё, что может упасть, стоит до первой записи, а сами записи идут подряд, без единой строки между ними.

В памяти этого достаточно: между log.push и store.write падать нечему, а смерть процесса уносит обе половины разом. На диске — нет: две записи на диск — два отдельных действия, и систему, которая убивает процесс, порядок строк в коде не остановит. Там один шаг делается одним из двух способов. Первый — писать одну половину: на диск ложится только журнал, а строки собирает свёртка; это следующая статья. Второй — транзакция базы, которая при сбое откатывает обе половины: withTransactionAsync в expo-sqlite, последняя статья главы.

Журнал вместе с хранилищем переезжает в подложку следующей статьи: createJournal, apply и fold. Там процесс «убьют» по-настоящему — выбросят память, — и журнал придётся поднимать с диска.