Ссылки снаружи и переход по уведомлению

Чтобы система отдавала ссылки «Подходу», у приложения должна быть своя схема — начало адреса вроде podhod://. Её объявляют в конфиге Expo одной строкой, а в нативные проекты её переносит prebuild: плагин withScheme из @expo/config-plugins пишет схему в CFBundleURLSchemes файла Info.plist и в intent-filter с категорией BROWSABLE в AndroidManifest. Это этаж Expo, и в песочнице конфига нет.

// app.config.js «Подхода», фрагмент
module.exports = {
  expo: {
    name: "Подход",
    slug: "podhod",
    // своя схема: ссылки вида podhod://exercise/bench система отдаёт этому приложению
    scheme: "podhod",
  },
};

В приложении автора на том же месте стоит scheme: 'appstarter'. Своя схема — не единственный вид ссылки, которая откроет карточку жима:

Ссылку для кнопки «Поделиться» руками не склеивают: createURL("/exercise/bench") из expo-linking сам выберет обёртку. В её описании перечислено: в сборке — <scheme>://path, в Expo Go — exp://128.0.0.1:8081/--/path.

Маршрутизатору из прошлых статей нужен путь — /exercise/bench. Самое очевидное — разобрать ссылку стандартным URL и взять pathname. Прогноз: что напечатают две строки — для своей схемы и для веб-адреса?

// ссылка на карточку жима — такой её пришлёт тренер в мессенджере
const link = new URL("podhod://exercise/bench");
console.log(link.protocol, link.host, link.pathname);

// та же карточка веб-адресом — так выглядит универсальная ссылка
const web = new URL("https://podhod.app/exercise/bench");
console.log(web.protocol, web.host, web.pathname);

У веб-адреса путь такой, как ждали, а у своей схемы exercise уехал в хост, и в пути остался один /bench. Ошибки нет: по стандарту URL всё, что стоит сразу после //, — хост, какой бы ни была схема. У https там домен, у podhod — первый сегмент нашего адреса. Поэтому expo-router склеивает их обратно: в build/fork/extractPathFromURL.js функция fromDeepLink собирает путь из res.host, res.pathname и строки запроса.

Остальное — особые случаи, и миниатюра берёт их у той же функции expo-router: веб-адрес теряет схему и домен, у ссылки Expo Go путь идёт после /--/, а готовый путь проходит как есть. Маршрутизатор прошлых статей — routesFrom, match и notFound — в подложке. Прогноз: куда поведёт каждая из пяти ссылок?

// подложка: маршрутизатор прошлых статей — routesFrom, match и notFound
type Params = Record<string, string | string[]>;
type Route = { file: string; parts: string[]; layouts: string[] };
type Found = { file: string; params: Params; layouts: string[] };
declare function routesFrom(keys: string[], platform: string): Route[];
declare function match(routes: Route[], url: string): Found | null;
declare function notFound(keys: string[], url: string): Found | null;

// то же, что extractExactPathFromURL в expo-router 57, без особых случаев: от ссылки остаётся путь
function toPath(url: string): string {
  // уже путь — так его вернёт, например, +native-intent
  if (url.startsWith("/")) return url;
  // универсальная ссылка — обычный веб-адрес: схема и домен отрезаются
  if (/^https?:\/\//.test(url)) {
    const web = new URL(url);
    return web.pathname + web.search;
  }
  // Expo Go: путь приложения начинается после /--/
  const expoGo = /^exps?:\/\/.*?\/--\/(.*)$/.exec(url);
  if (expoGo) return "/" + expoGo[1];
  // своя схема: первый сегмент URL считает хостом, поэтому хост и путь склеиваются
  const link = new URL(url);
  return "/" + link.host + link.pathname + link.search;
}

const keys = ["./(tabs)/index.tsx", "./(tabs)/catalog.tsx", "./exercise/[id].tsx", "./+not-found.tsx"];
const routes = routesFrom(keys, "ios");
const links = ["podhod://exercise/bench", "exp://192.168.1.5:8081/--/exercise/deadlift", "https://podhod.app/catalog", "podhod://", "podhod://workout/7"];
for (const url of links) {
  const path = toPath(url);
  console.log(url, "→", path, "→", (match(routes, path) ?? notFound(keys, path))?.file);
}

Голая схема podhod:// дала корень, и на нём открылась тренировка: так и надо, приложение запустили ссылкой без пути. Ссылка на экран, которого нет, приложение не роняет, а приходит в +not-found из прошлой статьи. Настоящая extractExpoPathFromURL из expo-router 57.0.16, запущенная в Node на тех же ссылках, вернула те же пути, только без первого слеша. Ссылку exp:// она разбирает так только внутри Expo Go — для прогона ей подложили признак Expo Go, — а в своей сборке такие ссылки не приходят.

Путь из ссылки достаём. Теперь — откуда ссылка берётся. Приём ссылок — нижний этаж, Linking из самого React Native: тот единственный экспорт со словом Link в имени, что нашёлся среди 61 в статье «Экраны на useState». Дверей у него две, потому что и путей у ссылки в приложение два:

В песочнице обе двери есть, но ведут не туда. Прогноз: что вернёт getInitialURL здесь?

const { Linking, Platform } = ReactNative;

console.log(Platform.OS);
// ссылка, которой система запустила процесс; с иконки на телефоне — null
Linking.getInitialURL().then((url) => console.log("начальная ссылка:", url));

Первая строка — честное напоминание: Platform.OS здесь web, песочница — браузерный кадр, а не телефон. about:srcdoc — адрес самого этого кадра. Linking из react-native-web 0.21 никакого запуска не знает: при загрузке модуля он запоминает window.location.href и отдаёт его как начальную ссылку. А событие url в браузере не придёт никогда: в открытую вкладку ссылки снаружи не присылают, и сам react-native-web шлёт подписчикам только onOpen — когда страница открывает ссылку сама, через openURL.

Поэтому телефон для этой статьи собран моделью. Она в подложке. launch запускает процесс — с иконки или ссылкой, — kill его выгружает, а openLink — это человек, нажавший ссылку: в живой процесс она приходит событием, а без процесса запускает его. Объект linking объявлен в примерах типом настоящего Linking, так что вызовы компилятор проверяет по типам react-native. Там же лежит ExpoRoot — навигатор прошлых статей со своим router и его очередью переходов, как у expo-router, — и экраны «Подхода», которые отмечают в консоли, что появились.

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

// подложка: маршрутизатор, стек и Navigator прошлых статей, экраны «Подхода» в podhodApp,
// toPath из примера выше, ExpoRoot с router и модель телефона: launch, kill, openLink и linking
declare function podhodApp(rootLayout: () => React.ReactNode): object;
declare function ExpoRoot(props: { app: object }): React.ReactElement;
declare function Stack(): React.ReactNode;
declare const router: { push(href: string): void };
declare const linking: Pick<typeof ReactNative.Linking, "getInitialURL" | "addEventListener">;
declare function toPath(url: string): string;
declare function launch(app: React.ReactElement, how?: { url: string }): void;
declare function kill(): void;
declare function openLink(url: string): void;

function RootLayout() {
  React.useEffect(() => {
    // процесс жив — ссылку система присылает событием url
    const sub = linking.addEventListener("url", ({ url }) => router.push(toPath(url)));
    return () => sub.remove();
  }, []);
  return <Stack />;
}

launch(<ExpoRoot app={podhodApp(RootLayout)} />);
setTimeout(() => openLink("podhod://exercise/bench"), 100);
// телефон лёг в карман, и к вечеру система выгрузила процесс
setTimeout(kill, 200);
setTimeout(() => openLink("podhod://exercise/squat"), 300);

Днём ссылка пришла событием в живой процесс, и карточка открылась. Вечером процесса не было: ссылка его запустила и лежит в getInitialURL, а подписка появилась позже и события не получила — его и не было. Человек видит тренировку вместо жима. Лечится одной строкой в том же эффекте: linking.getInitialURL().then((url) => { if (url) router.push(toPath(url)); }). Двери читают вместе и всегда: одна ловит запуск, другая — всё, что пришло после.

Ссылка, которая запустила процесс, событием не приходит: её забирают вопросом getInitialURL. Та же пара — «чем запустили» и «что пришло потом» — есть у нажатий на уведомление.

В корневой раскладке навигатор уже есть. Но первым кадром приложения навигатор бывает не всегда. Пока читается диск — о нём глава 6 — и грузятся шрифты, корень рисует сплэш, а навигатор появляется позже. Разобрать, чем запустили процесс, хочется тут же, на старте. router в подложке устроен как router из expo-router 57: push не выполняет переход на месте, а кладёт его в очередь, и разбирает эту очередь эффект контейнера навигации — в модели это ExpoRoot. Прогноз: процесс запустили ссылкой на жим, а корень 300 мс показывает сплэш. Что станет с переходом?

// подложка: та же, что в прошлом примере
declare function podhodApp(rootLayout: () => React.ReactNode): object;
declare function ExpoRoot(props: { app: object; awaitLink?: number }): React.ReactElement;
declare function Stack(): React.ReactNode;
declare const router: { push(href: string): void; back(): void };
declare const linking: Pick<typeof ReactNative.Linking, "getInitialURL" | "addEventListener">;
declare function toPath(url: string): string;
declare function launch(app: React.ReactElement, how?: { url: string }): void;
const { Text } = ReactNative;

function App() {
  const [hydrated, setHydrated] = React.useState(false);
  React.useEffect(() => {
    // чем запустили процесс, известно сразу — разбираем, пока идёт сплэш
    linking.getInitialURL().then((url) => {
      if (url) router.push(toPath(url));
    });
    // сплэш: корень ждёт диск и шрифты, навигатора в дереве ещё нет
    const timer = setTimeout(() => setHydrated(true), 300);
    return () => clearTimeout(timer);
  }, []);
  return hydrated ? <ExpoRoot app={podhodApp(Stack)} /> : <Text>Подход</Text>;
}

launch(<App />, { url: "podhod://exercise/bench" });

Переход дождался навигатора и выполнился, хотя в миг вызова всё дерево состояло из одного сплэша. Очередь тут не наша — она внутри expo-router. router.push по обычному адресу сам ничего не делает: в build/global-state/router.js функция linkTo кладёт действие ROUTER_LINK в routingQueue и возвращается. Разбирает очередь useImperativeApiEmitter: он подписан на неё через useSyncExternalStore и в эффекте зовёт run. Зовут этот хук в форке NavigationContainer, а форк — предок всего дерева, и его эффект выполняется последним, когда навигатор ниже уже смонтирован. Маршрутизатор из «Собираем маршруты» так не умел: пока навигатора нет, его переход упирался в пустоту и пропадал молча. Очередь — лекарство ровно от этого.

// подложка: та же
declare function podhodApp(rootLayout: () => React.ReactNode): object;
declare function ExpoRoot(props: { app: object; awaitLink?: number }): React.ReactElement;
declare function Stack(): React.ReactNode;
declare const router: { push(href: string): void; back(): void };
declare const linking: Pick<typeof ReactNative.Linking, "getInitialURL" | "addEventListener">;
declare function toPath(url: string): string;
declare function launch(app: React.ReactElement, how?: { url: string }): void;
const { Text } = ReactNative;

function App() {
  const [hydrated, setHydrated] = React.useState(false);
  React.useEffect(() => {
    linking.getInitialURL().then((url) => {
      if (!url) return;
      router.push(toPath(url));
      // передумали: экран входа за спиной больше не нужен
      router.back();
    });
    const timer = setTimeout(() => setHydrated(true), 300);
    return () => clearTimeout(timer);
  }, []);
  return hydrated ? <ExpoRoot app={podhodApp(Stack)} /> : <Text>Подход</Text>;
}

launch(<App />, { url: "podhod://exercise/bench" });

Значит ли это, что о моменте можно не думать? Нет: у самой очереди есть окно, в котором переход пропадает молча. Контейнер навигации сначала спрашивает начальную ссылку и, пока ответа нет, вместо навигатора рисует запасную разметку. На Android это ожидание длится до 150 мс: build/fork/useLinking.native.js пускает Linking.getInitialURL() наперегонки с таймаутом, и рядом стоит ссылка на issue 25675 в репозитории React Native. Контейнер в этот миг уже смонтирован и очередь разбирает — вот только навигатора под ним ещё нет. В модели такое ожидание включает свойство awaitLink. Прогноз: процесс запустили с иконки, а на 50-й миллисекунде человек нажал уведомление «Отдых окончен» с адресом карточки жима. Где он окажется?

// подложка: та же и модель уведомлений — notifications и tapNotification
declare function podhodApp(rootLayout: () => React.ReactNode): object;
declare function ExpoRoot(props: { app: object; awaitLink?: number }): React.ReactElement;
declare function Stack(): React.ReactNode;
declare const router: { push(href: string): void; back(): void };
type TapResponse = { notification: { request: { content: { data: { url: string } } } } };
declare const notifications: {
  getLastNotificationResponse(): TapResponse | null;
  addNotificationResponseReceivedListener(listener: (response: TapResponse) => void): { remove(): void };
};
declare function launch(app: React.ReactElement, how?: { url?: string; tap?: { url: string } }): void;
declare function tapNotification(data: { url: string }): void;

// дверь слушают с самого старта JS — навигатора в этот момент может ещё не быть
notifications.addNotificationResponseReceivedListener((r) => {
  router.push(r.notification.request.content.data.url);
});

// awaitLink: контейнер ждёт начальную ссылку и рисует пока запасную разметку
launch(<ExpoRoot app={podhodApp(Stack)} awaitLink={150} />);
// отдых кончился, человек нажал уведомление — контейнер ещё ждёт
setTimeout(() => tapNotification({ url: "/exercise/bench" }), 50);

Человек нажал уведомление о жиме и остался на тренировке. Ни ошибки, ни строки в консоли — переход исчез. Виноват порядок строк в run: очередь сначала обнуляется, а навигатор проверяется после, и разобранные действия деть уже некуда. В исходнике рядом стоит признание — TODO «Consider warning when ref.current is null — actions are silently dropped». Таймером это не лечится: длительность ожидания зависит от платформы и от того, ответит ли натив — на iOS ссылка приходит синхронно, через getLinkingURL() из expo-linking, на Android идёт та самая гонка со 150 мс. Нужна своя очередь, и главное в ней не хранилище, а место, откуда её выпускают: такое, которого не существует, пока навигатора нет. Корневая раскладка ровно такая — контейнер рисует её только вместе с навигатором. Прогноз: тот же запуск, на 50-й миллисекунде уведомление, на 100-й — ссылка тренера на приседания. Что откроется и в каком порядке?

// подложка: та же
declare function podhodApp(rootLayout: () => React.ReactNode): object;
declare function ExpoRoot(props: { app: object; awaitLink?: number }): React.ReactElement;
declare function Stack(): React.ReactNode;
declare const router: { push(href: string): void; back(): void };
declare const linking: Pick<typeof ReactNative.Linking, "getInitialURL" | "addEventListener">;
declare function toPath(url: string): string;
type TapResponse = { notification: { request: { content: { data: { url: string } } } } };
declare const notifications: {
  getLastNotificationResponse(): TapResponse | null;
  addNotificationResponseReceivedListener(listener: (response: TapResponse) => void): { remove(): void };
};
declare function launch(app: React.ReactElement, how?: { url?: string; tap?: { url: string } }): void;
declare function tapNotification(data: { url: string }): void;
declare function openLink(url: string): void;

// своя очередь: пока навигатора нет, адреса ждут в порядке прихода
const pending: string[] = [];
let ready = false;
function openHref(href: string) {
  if (ready) router.push(href);
  else pending.push(href);
}

function RootLayout() {
  // контейнер рисует раскладку только вместе с навигатором — здесь он уже есть
  React.useEffect(() => {
    ready = true;
    for (const href of pending.splice(0)) router.push(href);
    return () => { ready = false; };
  }, []);
  return <Stack />;
}

notifications.addNotificationResponseReceivedListener((r) => openHref(r.notification.request.content.data.url));
linking.addEventListener("url", ({ url }) => openHref(toPath(url)));

launch(<ExpoRoot app={podhodApp(RootLayout)} awaitLink={150} />);
setTimeout(() => tapNotification({ url: "/exercise/bench" }), 50);
setTimeout(() => openLink("podhod://exercise/squat"), 100);

Оба перехода дождались навигатора и вышли в том порядке, в каком пришли: под приседаниями лежит жим, под ним — тренировка, и «назад» пройдёт этот путь обратно. Откуда адрес, очереди всё равно: openHref принимает строку. Уведомление несёт адрес экрана в своих data, и дальше его путь тот же, что у ссылки. Модель уведомлений урезана до этого пути. Настоящие getLastNotificationResponse и подписку из expo-notifications — с полной формой ответа и тем, как натив хранит нажатие до старта JavaScript, — разберёт статья «Уведомления: планировщик, канал, нажатие».

// подложка: маршрутизатор, стек, Navigator, экраны «Подхода», toPath, ExpoRoot с router
// и модель телефона со ссылками и уведомлениями
declare function podhodApp(rootLayout: () => React.ReactNode): object;
declare function ExpoRoot(props: { app: object; awaitLink?: number }): React.ReactElement;
declare function Stack(): React.ReactNode;
declare const router: { push(href: string): void; back(): void };
declare const linking: Pick<typeof ReactNative.Linking, "getInitialURL" | "addEventListener">;
declare function toPath(url: string): string;
type TapResponse = { notification: { request: { content: { data: { url: string } } } } };
declare const notifications: {
  getLastNotificationResponse(): TapResponse | null;
  addNotificationResponseReceivedListener(listener: (response: TapResponse) => void): { remove(): void };
};
declare function launch(app: React.ReactElement, how?: { url?: string; tap?: { url: string } }): void;
declare function tapNotification(data: { url: string }): void;
declare function pressSystemBack(): void;
const { Text } = ReactNative;

// своя очередь: до готовности навигатора адреса ждут, после — идут сразу
const pending: string[] = [];
let ready = false;
function openHref(href: string) {
  if (ready) router.push(href);
  else pending.push(href);
}

// двери процесса слушают с его старта — навигатора в этот момент может ещё не быть
function listenOutside() {
  const tap = notifications.getLastNotificationResponse();
  if (tap) openHref(tap.notification.request.content.data.url);
  linking.getInitialURL().then((url) => {
    if (url) openHref(toPath(url));
  });
  linking.addEventListener("url", ({ url }) => openHref(toPath(url)));
  notifications.addNotificationResponseReceivedListener((r) => openHref(r.notification.request.content.data.url));
}

// корневая раскладка выпускает очередь: она рисуется только под смонтированным навигатором
function useOutsideQueue() {
  React.useEffect(() => {
    ready = true;
    for (const href of pending.splice(0)) router.push(href);
    return () => { ready = false; };
  }, []);
}

function RootLayout() {
  useOutsideQueue();
  return <Stack />;
}

function App() {
  const [hydrated, setHydrated] = React.useState(false);
  React.useEffect(() => {
    listenOutside();
    const timer = setTimeout(() => setHydrated(true), 300);
    return () => clearTimeout(timer);
  }, []);
  return hydrated ? <ExpoRoot app={podhodApp(RootLayout)} awaitLink={150} /> : <Text>Подход</Text>;
}

launch(<App />, { url: "podhod://exercise/bench" });
// отдых кончился, уведомление нажато, когда навигатор давно готов
setTimeout(() => tapNotification({ url: "/exercise/squat" }), 500);
setTimeout(pressSystemBack, 600);
setTimeout(pressSystemBack, 700);

В настоящем приложении обе двери Linking за вас открывает expo-router — этаж Expo. Ту же гонку он решает с другой стороны: не ссылка ждёт навигатор, а навигатор ждёт ссылку. Контейнер навигации — форк NavigationContainer в build/fork — сначала спрашивает начальную ссылку и, пока ответа нет, вместо навигатора рисует запасную разметку:

// expo-router 57.0.16 · build/fork/NavigationContainer.js, фрагмент
const [isResolved, initialState] = (0, useThenable_1.useThenable)(getInitialState);
react_1.default.useImperativeHandle(ref, () => refContainer.current);
const isLinkingReady = rest.initialState != null || !isLinkingEnabled || isResolved;
if (!isLinkingReady) {
    // This is temporary until we have Suspense for data-fetching
    // Then the fallback will be handled by a parent `Suspense` component
    return (0, jsx_runtime_1.jsx)(native_1.ThemeProvider, { value: theme, children: fallback });
}

Ссылка холодного старта в expo-router — не переход, а начальное состояние. Путь из неё проходит тот же getStateFromPath, что и любой адрес, и навигатор монтируется сразу с этим стеком. Подписку на событие url ставит хук useLinking того же контейнера. Своя очередь для ссылок поэтому не нужна дважды: их ждёт сам контейнер, а переходы, отданные router, и так ложатся в его очередь. Нужна она против одного окна — того, в котором контейнер ещё ждёт ссылку, а run уже выбрасывает очередь в пустоту.

По пути ссылка проходит через +native-intent — служебный файл из прошлой статьи. Начальную ссылку отдаёт его функции redirectSystemPath сам getLinkingConfig, с initial: true; каждую пришедшую событием — подписка subscribe из link/linking.js, которую тот же конфиг и ставит, с initial: false. Дальше идёт то, что она вернула. Несмотря на имя, в path приходит ссылка целиком, со схемой. Сигнатура — из типов expo-router:

// expo-router 57.0.16 · build/types.d.ts, поле типа NativeIntent
redirectSystemPath?: (event: {
    path: string;
    initial: boolean;
}) => Promise<string | null> | string | null;

Описание рядом добавляет два правила. Если функция вернула null, перехода не будет и приложение останется на текущем экране. А ошибка, брошенная внутри, может уронить приложение, поэтому код в ней оборачивают в try/catch. Переписать старые ссылки сайта в адреса приложения — вторая задача.

Начальное состояние из ссылки — ровно то, что в ссылке, и ничего сверх. Прогон настоящих getRoutes и getStateFromPath из expo-router 57.0.16 в Node на файлах «Подхода»:

Без anchor под карточкой жима пусто, и первая же системная «назад» уводит из приложения: стек из статьи «Собираем стек экранов с историей» с первой записи отдаёт нажатие системе. Экспорт unstable_settings с полем anchor называет маршрут, который в стеке раскладки всегда лежит первым. getRoutesCore.js читает его как unstable_settings.anchor, а старое имя initialRouteName принимает запасным. Приставка unstable_ честно предупреждает: форма настройки может смениться. Собрать то же в миниатюре — первая задача.

// app/_layout.tsx — корневая раскладка «Подхода»
import { Stack } from "expo-router";

// холодный старт по ссылке кладёт под её экран вкладки, а не пустоту
export const unstable_settings = { anchor: "(tabs)" };

export default function RootLayout() {
  return (
    <Stack>
      <Stack.Screen name="(tabs)" options={{ headerShown: false }} />
      <Stack.Screen name="exercise/[id]" options={{ title: "Упражнение" }} />
    </Stack>
  );
}

Листинги статьи проверил tsc 6.0.3 на настоящих типах expo-router 57.0.16 — ни одной ошибки. Чтобы проверка точно смотрела в эти типы, рядом лежал пробный файл с двумя заведомыми ошибками: router.push(42) и строка в числе. Нашлись обе.

Нажатие на уведомление через +native-intent не проходит: это не системная ссылка, а событие модуля expo-notifications, и отдать его router — ваша работа. Вот как это сделано в приложении автора — не в «Подходе», а в рабочем проекте на Expo SDK 57. Компонент ничего не рисует и стоит в корневой раскладке, рядом с <Stack>:

// apps/mobile/src/app/push-notifications/push-notifications.tsx — приложение автора, фрагмент
export function PushNotifications() {
  const router = useRouter();
  const utils = trpc.useUtils();
  const token = useSession((s) => s.token);
  // навигатор монтируется не мгновенно, а переход до этого момента expo-router
  // отвергает — на холодном старте по уведомлению это обычное дело
  const navigatorReady = Boolean(useRootNavigationState()?.key);

  // …регистрация токена и обновление данных пропущены

  // Нажатие. Два случая: приложение работало (подписка) и приложение было
  // закрыто, а нажатие его и открыло (последний сохранённый ответ).
  useEffect(() => {
    if (!navigatorReady) return;
    const open = (payload: NotificationPayload) =>
      router.push({ pathname: '/notes/[id]', params: { id: payload.noteId } });
    const initial = takeInitialPushPayload();
    if (initial) open(initial);
    return addPushTapListener(open);
  }, [navigatorReady, router]);

Готовность здесь — не эффект раскладки, а ключ состояния корневого навигатора: useRootNavigationState() отдаёт это состояние (в hooks/useRootNavigationState.js это getParent(…).getState()). Ждёт этот ключ, однако, куда меньше, чем кажется. Состояние навигатора собирается во время рендера — useNavigationBuilder считает его в useMemo, а ключ вроде stack-… выдаёт StackRouter.getInitialState, — поэтому у компонента внутри навигатора ключ есть уже на первом рендере. Работает гард по другой причине: компонент живёт под контейнером и не рисуется, пока тот показывает запасную разметку, — то самое окно, в котором переход пропадает. Комментарий в этом файле про «переход до этого момента expo-router отвергает» писался под прежние выпуски: в 57 обычный router.push не отвергается, а ждёт в очереди, и настоящая готовность в смысле assertIsReady наступает даже позже ключа — isReady() в BaseNavigationContainer.js (строка 158) это «есть ли подписчик на focus», а подписываются навигаторы в своих эффектах. Очереди в JavaScript у автора нет: её роль играет натив. expo-notifications помнит последнее нажатие, и эффект, дождавшись рендера под навигатором, забирает его через takeInitialPushPayload, а та читает getLastNotificationResponse. Главное совпадает с миниатюрой: адрес отдают router из места, которое существует только при смонтированном навигаторе.

Проверить ссылку без мессенджера можно из терминала: команда отдаёт ссылку симулятору или эмулятору так же, как это сделала бы система. Если приложение закрыто, получится холодный старт, если открыто — событие url.

# iOS: ссылка в запущенный симулятор
$ xcrun simctl openurl booted "podhod://exercise/bench"
# Android: тот же intent с ACTION_VIEW, который читает IntentModule
$ adb shell am start -W -a android.intent.action.VIEW -d "podhod://exercise/bench"

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