Главная копия — в телефоне

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

declare const net: { online: boolean };
declare function createServerMain(): ServerMain;
type SetDraft = { workoutId: string; exercise: string; kg: number; reps: number };
interface ServerMain {
  listSets(workoutId: string): Promise<SetDraft[]>;
  addSet(draft: SetDraft): Promise<SetDraft & { id: number }>;
  stats(): { saved: number; errors: number; waitedMs: number };
}

// визит в зал: открыть тренировку, записать пять подходов, открыть снова
async function gymVisit(server: ServerMain) {
  // ошибку приложение показывает и живёт дальше, как тост «нет связи»
  const attempt = (call: () => Promise<unknown>) => call().catch(() => null);
  await attempt(() => server.listSets("w1"));
  for (let n = 1; n <= 5; n++) {
    await attempt(() => server.addSet({ workoutId: "w1", exercise: "bench", kg: 80, reps: 5 }));
  }
  await attempt(() => server.listSets("w1"));
  return server.stats();
}

(async () => {
  console.log("сеть есть:", await gymVisit(createServerMain()));
  net.online = false;
  console.log("сети нет:", await gymVisit(createServerMain()));
})();

Со связью всё сохранилось, но семь запросов по 400 мс — почти три секунды колеса загрузки на пять нажатий. Без связи — ноль из пяти: каждое нажатие честно подождало 1200 мс и кончилось ошибкой. Ошибок семь, а не пять, потому что открыть тренировку — тоже запрос, и сценарий делает его дважды. 8400 мс человек с гантелью в руке смотрел на колесо, а в итоге дневник пуст. Повтор не спасёт: сети не будет до выхода из зала, а веса к тому времени забудутся.

На телефоне бывает хуже, чем в заглушке. 1200 мс здесь — таймер самого приложения, а своего срока у fetch в React Native нет. fetch там — полифил whatwg-fetch поверх XMLHttpRequest, его подключает Libraries/Network/fetch.js:

// whatwg-fetch 3.6.20 — его ставит react-native 0.86; dist/fetch.umd.js, сокращено
xhr.onerror = function() {
  setTimeout(function() {
    reject(new TypeError('Network request failed'));
  }, 0);
};

xhr.ontimeout = function() {
  setTimeout(function() {
    reject(new TypeError('Network request timed out'));
  }, 0);
};

Без сети промис отклоняется с TypeError: Network request failed. Обработчик ontimeout тоже есть, но сам xhr.timeout полифил не ставит нигде в файле — срабатывать ему не от чего. Этажом ниже, на Android, сетевой модуль создаёт клиент OkHttp с connectTimeout(0), readTimeout(0) и writeTimeout(0), и в OkHttpClientProvider.kt react-native 0.86 над ними так и написано: «No timeouts by default» — ноль у OkHttp значит «без срока». Если сеть в зале есть, но сервер не отвечает, запрос висит, пока не сдастся система или ваш собственный таймер.

Колесо загрузки и «нет связи» — не плохой дизайн заглушки, а прямое следствие того, где лежит правда. Пока хозяин — сервер, экран без сети может только ждать и извиняться.

Выход один: главная копия должна лежать там, где человек, — в телефоне. Сервер при этом не пропадает: в главе 7 он станет местом, куда дневник уезжает, когда связь появится, и откуда приезжает на второе устройство. Но экран спрашивает уже не его.

Хранилище «Подхода» — объект в памяти JavaScript. Строки лежат в Map по id, write кладёт или заменяет строку, get и list читают, subscribe даёт экранам узнать о записи, а version растёт на каждой записи. Ни одного промиса: запись и чтение укладываются в один синхронный кусок кода, поэтому ждать нечего и сломаться по дороге негде. Id пока наивные — «s1», «s2»; откуда на самом деле берутся имена строк, когда сервера рядом нет, — предмет следующей статьи. Сценарий тот же, что у заглушки. Прогноз для трёх строк: сколько сохранено и какие из сравнений дадут true?

type SetRow = { id: string; workoutId: string; exercise: string; kg: number; reps: number };

function createStore() {
  const rows = new Map<string, SetRow>();
  const listeners = new Set<() => void>();
  let version = 0;
  let snapshot = { version, rows: [] as SetRow[] };
  return {
    write(row: SetRow) {
      rows.set(row.id, row);
      version += 1;
      listeners.forEach((listener) => listener());
    },
    get: (id: string) => rows.get(id),
    list: () => {
      if (snapshot.version !== version) snapshot = { version, rows: [...rows.values()] };
      return snapshot.rows;
    },
    subscribe: (listener: () => void) => {
      listeners.add(listener);
      return () => {
        listeners.delete(listener);
      };
    },
    get version() {
      return version;
    },
  };
}

// тот же визит в зал: открыть, записать пять подходов, открыть снова
const store = createStore();
const opened = store.list();
for (let n = 1; n <= 5; n++) {
  store.write({ id: "s" + n, workoutId: "w1", exercise: "bench", kg: 80, reps: 5 });
}
console.log("сохранено:", store.list().length, "| подход s5:", store.get("s5")?.kg, "кг");
console.log("до записей и после — один массив:", opened === store.list());
console.log("два чтения подряд — один массив:", store.list() === store.list(), "| версия:", store.version);

Пять из пяти, и сети для этого не понадобилось вовсе: в коде нет ни одного await, а подход s5 читается строкой ниже записи. Два других сравнения — про то, как list отдаёт массив. Он не собирается заново на каждый вызов: хранилище помнит массив вместе с версией, при которой его собрало, и пересобирает только после записи. Поэтому массив до записей и массив после — разные объекты, а два чтения подряд — один и тот же. Зачем это нужно, покажет раздел про ловушку: React сравнивает то, что прочитал, по ссылке.

Хранилище — замыкание, а не класс: ни один его метод не трогает this. Это пригодится сразу же: экраны будут отдавать React функции хранилища поодиночке, store.list без скобок, и метод класса при таком вызове потерял бы свой объект. Это та самая потеря контекста из статьи «Потеря контекста и как её чинить» части I: у класса её обходят полями-стрелками, а здесь её обходит замыкание.

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

type SetRow = { id: string; workoutId: string; exercise: string; kg: number; reps: number };
interface Store {
  write(row: SetRow): void;
  list(): SetRow[];
  subscribe(listener: () => void): () => void;
}
interface Nav {
  replace(url: string): void;
}
declare const store: Store;
declare function useStack(first: string): [{ url: string }[], Nav];
declare function TabBar(props: { nav: Nav }): React.ReactElement;
const { View, Text, Pressable } = ReactNative;

// функция подписки и функция чтения — как в «Своём хуке» части IV
function useSets(): SetRow[] {
  return React.useSyncExternalStore(store.subscribe, store.list);
}

function Header() {
  const sets = useSets();
  console.log("шапка:", sets.length);
  return <Text style={{ fontSize: 18 }}>Подход · {sets.length}</Text>;
}

let nextId = 0; // откуда на самом деле берётся id — следующая статья
function Feed() {
  const sets = useSets();
  console.log("лента:", sets.map((s) => s.kg + "×" + s.reps).join(", ") || "пусто");
  const add = () => store.write({ id: "s" + ++nextId, workoutId: "w1", exercise: "bench", kg: 80, reps: 5 });
  return (
    <View>
      {sets.map((s) => <Text key={s.id}>{s.exercise}: {s.kg} × {s.reps}</Text>)}
      <Pressable testID="add" onPress={add}><Text>+ подход</Text></Pressable>
    </View>
  );
}

function Screens() {
  const [stack, nav] = useStack("/");
  const url = stack[stack.length - 1].url;
  return <View><TabBar nav={nav} />{url === "/" ? <Feed /> : <Text>справочник</Text>}</View>;
}

mount(<View style={{ gap: 8 }}><Header /><Screens /></View>);
setTimeout(() => fireEvent.press("add"), 50);
setTimeout(() => fireEvent.press("tab-catalog"), 100);
setTimeout(() => fireEvent.press("tab-workout"), 150);

Одна запись — и шапка, и лента перерисовались, хотя друг о друге они не знают: обе подписаны на хранилище, а не держат копию в своём состоянии. Уход в справочник не напечатал ничего: лента ушла из дерева, шапка не изменилась. А возврат — одна строка, и подход в ней уже есть. Лента смонтировалась заново, но первая же её отрисовка прочитала хранилище синхронно: ни эффекта с запросом, ни «загрузка…», ни мелькнувшей пустоты.

Три состояния экрана из части IV — статьи про use() и Suspense, границы ошибок и loading.tsx — здесь экрану не нужны: у чтения из памяти нечему «грузиться» и нечему «не удаться». Ожидание останется в одном месте — пока хранилище поднимается с диска на старте приложения; ему посвящена статья «Первый кадр: пока хранилище читается».

Отличие от части IV не в React — useSyncExternalStore в React Native тот же самый, — а в том, где стоит программа. В Next.js данные читались на сервере, а у телефона сервера под рукой нет: весь «Подход» — один процесс JavaScript на устройстве, и хранилище живёт в его памяти. Память процесса на телефоне ненадёжна по-своему: свёрнутое приложение система выгружает, когда ей нужна память, и никого не спрашивает. Пока хранилище только в памяти, такая выгрузка стирает дневник целиком, поэтому через статью под память ляжет диск.

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

type SetRow = { id: string; workoutId: string; exercise: string; kg: number; reps: number };
interface Store {
  write(row: SetRow): void;
  list(): SetRow[];
  subscribe(listener: () => void): () => void;
}
interface WorkoutProps {
  workoutId: string;
}
declare const store: Store;
const { Text } = ReactNative;

store.write({ id: "s1", workoutId: "w1", exercise: "bench", kg: 80, reps: 5 });
store.write({ id: "s2", workoutId: "w2", exercise: "squat", kg: 100, reps: 5 });

let renders = 0;
function WorkoutSets({ workoutId }: WorkoutProps) {
  renders += 1;
  // экрану нужны подходы одной тренировки — фильтруем прямо при чтении
  const sets = React.useSyncExternalStore(store.subscribe, () =>
    store.list().filter((s) => s.workoutId === workoutId),
  );
  return <Text>подходов в тренировке: {sets.length}</Text>;
}

mount(<WorkoutSets workoutId="w1" />);
setTimeout(() => console.log("отрисовок:", renders), 200);

React предупредил, и почти сразу экран упал: следом идут ошибка из подключённой библиотеки и сообщение React о том, что упал <WorkoutSets>. Функцию чтения — в документации React она называется getSnapshot — React зовёт на каждой отрисовке и после каждого оповещения и сравнивает результат с прошлым через Object.is. filter каждый раз возвращает новый массив, пусть и с теми же подходами, — значит, по мнению React, хранилище всё время меняется: он рисует снова и снова получает «новое». Отладочная сборка замечает это заранее — два вызова подряд дали разное, отсюда предупреждение, — а затем цикл упирается в предел вложенных обновлений. Текст этой второй ошибки песочница не показывает: браузер прячет сообщения ошибок, выброшенных из подключённой библиотеки. Граница ошибок из части IV его поймала бы: Maximum update depth exceeded — React ограничивает число вложенных обновлений. Счётчик показывает, сколько кругов успело пройти до падения.

На телефоне будет то же самое: это поведение самого React, а не react-native-web. Разница только в том, кто вас предупредит. Строка про кеширование getSnapshot есть лишь в отладочном рендерере React Native (ReactFabric-dev.js), в выпускном (ReactFabric-prod.js) её нет вовсе, а Maximum update depth exceeded есть в обоих. У пользователя экран упадёт без всякого предупреждения, поэтому такую ошибку надо увидеть до выпуска.

Лечится снимком по номеру версии, и половина работы уже сделана: list возвращает один и тот же массив, пока версия не сменилась. Отдаём React его, а фильтр переносим в отрисовку, под useMemo с этим массивом в зависимостях: новый отфильтрованный массив появится только тогда, когда хранилище правда изменилось. Прогноз: сколько отрисовок будет теперь, если после монтирования записать ещё один подход в эту тренировку?

type SetRow = { id: string; workoutId: string; exercise: string; kg: number; reps: number };
interface Store {
  write(row: SetRow): void;
  list(): SetRow[];
  subscribe(listener: () => void): () => void;
}
interface WorkoutProps {
  workoutId: string;
}
declare const store: Store;
const { Text } = ReactNative;

store.write({ id: "s1", workoutId: "w1", exercise: "bench", kg: 80, reps: 5 });
store.write({ id: "s2", workoutId: "w2", exercise: "squat", kg: 100, reps: 5 });

let renders = 0;
function WorkoutSets({ workoutId }: WorkoutProps) {
  renders += 1;
  // снимок — массив текущей версии: пока записей не было, это один и тот же объект
  const all = React.useSyncExternalStore(store.subscribe, store.list);
  const sets = React.useMemo(() => all.filter((s) => s.workoutId === workoutId), [all, workoutId]);
  console.log("подходов в тренировке:", sets.length);
  return <Text>подходов в тренировке: {sets.length}</Text>;
}

mount(<WorkoutSets workoutId="w1" />);
setTimeout(() => store.write({ id: "s3", workoutId: "w1", exercise: "bench", kg: 80, reps: 4 }), 50);
setTimeout(() => console.log("отрисовок:", renders), 200);

Две отрисовки — при монтировании и после записи — и ни одного предупреждения. Можно было написать и стрелку () => store.list(): важно не то, новая ли функция, а то, одинаков ли её результат, пока хранилище не менялось. Массив текущей версии одинаков по построению, поэтому снимок по версии — правило для всех читателей хранилища, а не только для этого экрана. Опасен любой снимок, который собирает новый объект: filter, map, { ...row }, Object.values.

Слово local-first ввело эссе «Local-first software: You own your data, in spite of the cloud» исследовательской лаборатории Ink & Switch — Мартин Клеппман, Адам Виггинс, Петер ван Харденберг и Марк Макгранаган, 2019 год. В нём семь идеалов, и честнее сразу сверить с ними «Подход», чем обещать все семь:

Четыре идеала «Подход» берёт целиком, «долгое сейчас» — частично, а два не берёт, и это выбор, а не упущение. Совместной работы в дневнике одного человека нет. Шифрование, при котором сервер не может прочесть данные, — отдельная большая тема, и она перевернула бы сервер части VI. Всё, что берём, стоит на одном: главная копия — в телефоне, и хранилище из этой статьи — её первый кирпич.

Хранилище переезжает в подложку следующей статьи. Там у него появится журнал: каждая запись станет операцией с id, рождённым на телефоне, — потому что номер от сервера, как у addSet в заглушке, без сети не получить.