Первый кадр: пока хранилище читается

Корень приложения на React Native монтирует не ваш код. Как только бандл загружен, платформа зовёт компонент, зарегистрированный через AppRegistry; expo-router регистрирует свой корень сам, в renderRootComponent.js. Первая отрисовка случается сразу. А boot ещё читает диск и идёт по лестнице, и на холодном старте, когда процесс поднимается с нуля, это занимает время. Что всё это время показывает экран?

Сначала о том, что человек видит до первого кадра. Пока JavaScript грузится, экран телефона закрыт нативным сплэшем — картинкой из конфига приложения, которую рисует сама система. В браузере такого нет, поэтому подложка его изображает: сплэш снимается сам, как только нарисовано первое содержимое, — так делает и expo-splash-screen, — и печатает, что открылось под ним. boot из подложки та же, что в прошлой статье, только печатает каждую ступень лестницы, чтобы было видно, когда идёт миграция. А ящик теперь отвечает через 10 мс настоящего времени: на холодном старте диск не мгновенный.

Экран дневника подписан на хранилище с первого кадра, как лента в статье «Главная копия — в телефоне», а boot наполняет хранилище, когда диск ответит. На диске — журнал версии 1.0 с одним подходом. Прогноз: какие кадры нарисуются и что увидит человек, когда сплэш снимется?

type Fields = Record<string, string | number>;
type Row = Fields & { id: string };
interface Store {
  list(): Row[];
  subscribe(listener: () => void): () => void;
}
interface FrameProps {
  text: string;
}
declare const store: Store;
declare const disk: { setItem(key: string, value: string): Promise<void> };
declare const fromV1: object;
declare function boot(device: string): Promise<unknown>;
const { Text } = ReactNative;

function Frame({ text }: FrameProps) {
  console.log("кадр:", text);
  return <Text>{text}</Text>;
}
// экран дневника подписан на хранилище, как в статье «Главная копия — в телефоне»
function DiaryScreen() {
  const sets = React.useSyncExternalStore(store.subscribe, store.list);
  return <Frame text={sets.length > 0 ? "дневник: " + sets.length : "у вас ещё нет тренировок"} />;
}

// так диск оставила версия 1.0; ящик выполняет запросы по порядку, и boot прочитает уже это
disk.setItem("podhod", JSON.stringify(fromV1));
// процесс поднимается с диска, как в прошлой статье
boot("A");
mount(<DiaryScreen />);

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

Этот механизм уже встречался в приложении автора, только в другом виде — мигающий редирект. Корневой маршрут stack-starter решает, куда отправить человека: с токеном — в приложение, без токена — на вход. Сессия читается из хранилища асинхронно, и до конца чтения «токена нет» значит «ещё не прочитали». Поэтому корень ждёт флаг hydrated:

// stack-starter, apps/mobile/src/app/root-redirect/root-redirect.tsx
import { Redirect } from 'expo-router';
import { useSession } from '@/entities/session/store';
import { Screen, Spinner } from '@/shared/ui';

/**
 * Корневой маршрут «/»: сам ничего не показывает, а решает, куда отправить.
 *
 * Ждём гидратацию сессии: до неё «токена нет» означает «ещё не прочитали»,
 * и человека с живой сессией выкинуло бы на экран входа при каждом запуске.
 */
export default function RootRedirect() {
  const { token, hydrated } = useSession();

  if (!hydrated) {
    return (
      <Screen scroll={false}>
        <Spinner />
      </Screen>
    );
  }
  return <Redirect href={token ? '/(main)' : '/(auth)/login'} />;
}

В «Подходе» редиректа на вход не будет, об этом последний раздел. Но мигание никуда не делось: мигающий редирект превратился в мигающее пустое состояние. Механизм тот же — первый кадр читает хранилище, которое ещё не прочитано с диска, — и лечится он так же, флагом. Слово «гидратация» здесь не то, что в статье части IV «Серверный компонент, SSR и гидратация — три разные вещи»: там React оживлял готовую разметку, а здесь хранилище наполняется с диска. Так называют флаг в сторах, отсюда и слово.

Флаг stack-starter — булев: hydrated либо false, либо true. Для дневника двух значений мало: открытие может кончиться отказом — схема новее приложения, испорченное значение на диске. «Прочитано» и «не прочитано, и уже не будет» — разные ответы, и экран у них разный. Поэтому состояний три: открывается, готова, не открылась. Записаны они размеченным объединением из части III — у отказа есть ошибка, у остальных нет.

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

type Fields = Record<string, string | number>;
type Row = Fields & { id: string };
interface Store {
  list(): Row[];
  subscribe(listener: () => void): () => void;
}
interface FrameProps {
  text: string;
}
declare const store: Store;
declare const disk: { setItem(key: string, value: string): Promise<void> };
declare const fromV1: object;
declare function boot(device: string): Promise<unknown>;
const { Text } = ReactNative;

function Frame({ text }: FrameProps) {
  console.log("кадр:", text);
  return <Text>{text}</Text>;
}
// экран дневника подписан на хранилище, как в статье «Главная копия — в телефоне»
function DiaryScreen() {
  const sets = React.useSyncExternalStore(store.subscribe, store.list);
  return <Frame text={sets.length > 0 ? "дневник: " + sets.length : "у вас ещё нет тренировок"} />;
}

type Opening =
  | { status: "opening" }
  | { status: "ready" }
  | { status: "failed"; error: Error };

// состояние открытия одно на весь процесс и живёт вне React — как hydrated у сессии
let opening: Opening = { status: "opening" };
const listeners = new Set<() => void>();
function settle(next: Opening) {
  opening = next;
  listeners.forEach((listener) => listener());
}
function subscribeOpening(listener: () => void) {
  listeners.add(listener);
  return () => {
    listeners.delete(listener);
  };
}

disk.setItem("podhod", JSON.stringify(fromV1));
boot("A").then(
  () => settle({ status: "ready" }),
  (error: Error) => settle({ status: "failed", error }),
);

function Root() {
  const open = React.useSyncExternalStore(subscribeOpening, () => opening);
  if (open.status === "opening") return <Frame text="сплэш" />;
  if (open.status === "failed") return <Frame text={"не открылась: " + open.error.message} />;
  return <DiaryScreen />;
}
mount(<Root />);

Ложь исчезла: первый кадр — «сплэш», а не «у вас ещё нет тренировок». Пустое состояние теперь бывает только у открытой базы, где хранилище правда пусто. Но лишний кадр остался. Нативный сплэш снялся на первом же содержимом, и под ним оказался наш JavaScript-сплэш: человек видит сплэш, потом ещё один сплэш, потом дневник. Если две картинки хоть чуть различаются, это видно как мигание. Флаг убирает ложное «пусто», но не лишний кадр — им займётся раздел «Первым кадром — дневник».

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

Открытие срывается по разным причинам. Схема на диске новее приложения — задача 2 прошлой статьи. Значение на диске испорчено: запись оборвалась, и JSON.parse бросает. На телефоне бывает занята база или кончилось место. Рука тянется к простому выходу: не держать человека на сплэше вечно, а считать, что данных нет. Так написан hydrate сессии в stack-starter:

// stack-starter, apps/mobile/src/entities/session/store.ts — сокращено
hydrate: async () => {
  try {
    const [token, rawUser] = await Promise.all([
      sessionStorage.getItem(TOKEN_KEY),
      sessionStorage.getItem(USER_KEY),
    ]);
    set({
      token: token ?? null,
      user: rawUser ? (JSON.parse(rawUser) as SessionUser) : null,
      hydrated: true,
    });
  } catch {
    // испорченная запись в хранилище не должна оставлять приложение
    // навсегда на спиннере: считаем, что сессии нет
    set({ hydrated: true });
  }
},

Для сессии это верное решение. Худшее, что случится, — человек войдёт ещё раз, и сервер выдаст новый токен. Проверим то же правило на дневнике. На диске журнал версии 1.2 со схемой 3, запущена откаченная 1.1, и человек в зале записывает присед. Прогноз для двух стратегий: что он увидит и что останется на диске?

type Fields = Record<string, string | number>;
type Row = Fields & { id: string };
type Saved = { schema: number; rowSeq: number; opSeq: number; log: object[] };
interface Journal {
  newId(): string;
  change(rowId: string, fields: Fields): Promise<void>;
}
interface Disk {
  getItem(key: string): Promise<string | null>;
  setItem(key: string, value: string): Promise<void>;
}
declare const store: { list(): Row[] };
declare const disk: Disk;
declare const fromV3: Saved;
declare function boot(device: string): Promise<Journal>;
declare function openJournal(device: string, saved: Saved): Journal;

// как hydrate сессии в stack-starter: не открылось — «считаем, что пусто»
async function bootOrEmpty(device: string) {
  try {
    return await boot(device);
  } catch {
    return openJournal(device, { schema: 2, rowSeq: 0, opSeq: 0, log: [] });
  }
}

// диск оставила 1.2 со схемой 3, а запущена 1.1; человек в зале записывает присед
async function visit(name: string, open: (device: string) => Promise<Journal>) {
  await disk.setItem("podhod", JSON.stringify(fromV3));
  try {
    const journal = await open("A");
    console.log(name + ": экран", store.list().length > 0 ? "«дневник»" : "«у вас ещё нет тренировок»");
    await journal.change(journal.newId(), { exercise: "squat", weightKg: 100, reps: 5 });
  } catch (error) {
    console.log(name + ": экран «не открылась:", (error as Error).message + "»");
  }
  const onDisk: Saved = JSON.parse((await disk.getItem("podhod")) ?? "null");
  console.log(name + ": на диске схема", onDisk.schema, "| операций", onDisk.log.length);
}

(async () => {
  await visit("сброс", bootOrEmpty);
  await visit("отказ", boot);
})();

Сброс показал пустой дневник. Человек поверил и записал присед, и первая же запись положила на диск журнал из одной операции на место журнала 1.2. Две операции исчезли, и неотправленная правка веса вместе с ними. Они были только на этом телефоне, и никакой сервер их не вернёт. Отказ показал «не открылась», и диск остался как был. Когда человек снова поставит 1.2, журнал откроется целиком.

Сброс здесь даже не в catch: openJournal с пустым журналом ничего не стирает. Стирает первая запись — она пишет на диск журнал целиком, а целиком он теперь пуст. Поэтому в состоянии «не открылась» писать нельзя вовсе, не только сносить. На экране «не открылась» — что случилось, человеческими словами. Кнопка «Повторить» — для временных сбоев вроде занятой базы. Для схемы из будущего — «Обновить приложение». И ни одной кнопки, которая пишет в журнал.

Пусто — это ответ открытой базы. Неоткрытая база не пуста, она неизвестна.

Нативный сплэш рисует система, ещё до того как запущен JavaScript. На iOS это launch screen из storyboard, который генерирует prebuild. Системный показ кончается быстро, поэтому expo-splash-screen кладёт тот же storyboard поверх корневого вида React Native, и картинка остаётся (SplashScreenManager.swift). На Android 12 и новее это системный API сплэша, а на старых версиях его повторяет библиотека AndroidX core-splashscreen. Модуль держит первый кадр окна, пока сплэш не велено снять (SplashScreenManager.kt). Картинку и её настройки разбирает статья «Иконка, сплэш, имя, версия» в главе 10. Здесь важно одно — когда сплэш снимается.

Сам по себе он снимается, как только React Native нарисовал первое содержимое: на Android — по метке CONTENT_APPEARED из ReactMarker, на iOS — по уведомлению RCTContentDidAppearNotification. Данных он не ждёт, поэтому в примерах выше и снялся на первом кадре. Отменяет это preventAutoHideAsync(): модуль ставит флаг preventAutoHideCalled, и сплэш стоит до hideAsync(). Звать её надо на уровне модуля, до первого содержимого. Отсюда рецепт: придержать сплэш, пока открытие не кончилось рисовать под ним null, а снять — когда исход известен. Прогноз: что увидит человек теперь?

type Fields = Record<string, string | number>;
type Row = Fields & { id: string };
interface Store {
  list(): Row[];
  subscribe(listener: () => void): () => void;
}
interface FrameProps {
  text: string;
}
declare const store: Store;
declare const disk: { setItem(key: string, value: string): Promise<void> };
declare const fromV1: object;
declare function boot(device: string): Promise<unknown>;
declare const SplashScreen: {
  preventAutoHideAsync(): Promise<boolean>;
  hideAsync(): Promise<void>;
};
const { Text } = ReactNative;

function Frame({ text }: FrameProps) {
  console.log("кадр:", text);
  return <Text>{text}</Text>;
}
// экран дневника подписан на хранилище, как в статье «Главная копия — в телефоне»
function DiaryScreen() {
  const sets = React.useSyncExternalStore(store.subscribe, store.list);
  return <Frame text={sets.length > 0 ? "дневник: " + sets.length : "у вас ещё нет тренировок"} />;
}

type Opening =
  | { status: "opening" }
  | { status: "ready" }
  | { status: "failed"; error: Error };

// состояние открытия одно на весь процесс и живёт вне React — как hydrated у сессии
let opening: Opening = { status: "opening" };
const listeners = new Set<() => void>();
function settle(next: Opening) {
  opening = next;
  listeners.forEach((listener) => listener());
}
function subscribeOpening(listener: () => void) {
  listeners.add(listener);
  return () => {
    listeners.delete(listener);
  };
}

// на уровне модуля: раньше, чем появится первое содержимое
SplashScreen.preventAutoHideAsync();
disk.setItem("podhod", JSON.stringify(fromV1));
boot("A").then(
  () => settle({ status: "ready" }),
  (error: Error) => settle({ status: "failed", error }),
);

function Root() {
  const open = React.useSyncExternalStore(subscribeOpening, () => opening);
  React.useEffect(() => {
    if (open.status !== "opening") SplashScreen.hideAsync();
  }, [open.status]);
  // под нативным сплэшем рисовать нечего: его всё равно не видно
  if (open.status === "opening") return null;
  if (open.status === "failed") return <Frame text={"не открылась: " + open.error.message} />;
  return <DiaryScreen />;
}
mount(<Root />);

Лестница прошла под нативным сплэшем, кадр дневника нарисовался под ним же, и сплэш снялся уже над дневником. Первое, что человек видит после картинки, — дневник. Вот что значит «монтировать после чтения диска»: корень смонтирован сразу, но дерево дневника появляется только после boot, а до того корень возвращает null. Нативный сплэш держится до конца миграции, и лишнего кадра нет.

hideAsync стоит в эффекте, а не в колбэке boot, и это не вкус. Эффект выполняется после коммита кадра, то есть когда дневник уже нарисован. Колбэк выполняется раньше, и сплэш открыл бы пустой экран. А условие — «не opening», а не «ready»: отказ — тоже конец ожидания, и экран «не открылась» надо показать. Что бывает иначе, покажет задача 1. В приложении автора сделано так же:

// echo-platform, apps/mobile/src/app/providers.tsx — сокращено
import * as SplashScreen from 'expo-splash-screen';

// сплэш держим до гидратации SecureStore, иначе мигает гостевой экран
void SplashScreen.preventAutoHideAsync();

export function Providers({ children }: ProvidersProps) {
  const hydrate = useSession((s) => s.hydrate);
  const hydrated = useSession((s) => s.hydrated);
  // шрифт продукта живёт в дизайн-системе, но загружает его приложение
  const fontsReady = useEchoFonts();

  useEffect(() => {
    void hydrate();
  }, [hydrate]);

  // сплэш снимаем, когда готово И хранилище, И шрифты: иначе первый кадр
  // отрисуется системным начертанием и переверстается на глазах
  useEffect(() => {
    if (hydrated && fontsReady) void SplashScreen.hideAsync();
  }, [hydrated, fontsReady]);
  // …
}

У expo-router свой порядок, и он вам не мешает. На старте корень сам просит сплэш подождать — через setTimeout, «чтобы вы успели раньше» — и снимает его, когда навигация готова. Но если вы вызвали preventAutoHideAsync, модуль это запоминает, и внутреннее снятие у expo-router ничего не делает: internalMaybeHideAsync проверяет, не взял ли управление пользователь. Подробнее — в той же статье главы 10.

В вебе нативного сплэша нет. Веб-файл expo-splash-screen — пустые функции:

// expo-splash-screen 57.0.8, src/SplashScreen.ts — файл для веба; комментарии сокращены
export async function preventAutoHideAsync(): Promise<boolean> {
  return false;
}

export function setOptions(options: SplashScreenOptions): void {}

export function hide(): void {}

export async function hideAsync(): Promise<void> {}

В веб-версии «Подхода» null на время чтения значил бы белую страницу, поэтому там ветка «открывается» рисует свой сплэш. Развести это можно файлом с расширением .web.tsx, как в статье «Одно приложение, три платформы». Песочница — тоже браузер, и настоящего expo-splash-screen в ней нет вовсе — по той же причине, по которой в статье про журнал листингом остался expo-crypto. Нативный сплэш здесь — модель из подложки, а «видно:» — её печать, а не снимок экрана.

Две оговорки. Первая — долгая миграция. Если ступень лестницы идёт долго, неподвижная картинка выглядит как зависание. Тогда сплэш снимают раньше и показывают экран «обновляем дневник» с ходом работы — это единственный случай, когда ветку «открывается» показывают нарочно. Вторая — всё это происходит на каждом холодном старте. Если система выгрузила приложение в фоне, возврат — это новый процесс: снова нативный сплэш и снова boot. Об этом статья «Свернули и вернулись» в главе 7.

В stack-starter гидратация сторожит дверь: без токена приложения нет, есть экран входа. В «Подходе» так нельзя. Дневник принадлежит человеку и лежит на его телефоне, и чтобы записать подход, входить никуда не нужно. Вход нужен синхронизации: серверу надо знать, чей журнал он принимает. Поэтому корень «Подхода» на вход не отправляет никогда. Он ждёт открытия базы и показывает дневник, а от токена зависит только строка синхронизации и кнопка «Войти, чтобы синхронизировать».

Токен кончился посреди работы — ответ 401 — это тоже не повод закрыть дневник. Как с этим обходится stack-starter и почему в local-first его уборка стёрла бы неотправленные подходы, разбирает статья «Свернули и вернулись». Здесь достаточно одного: токен — не ключ от дневника.

Состояние открытия, boot и модель нативного сплэша переезжают в подложку последней статьи главы. Там на место ящика встанет настоящая база expo-sqlite, и в её SQLiteProvider с onInit и useSuspense узнаются лестница и три состояния этой статьи.