Variable ReelsViewerInputSchemaConst
ReelsViewerInputSchema: Struct<
{
chainingPosition: optionalKey<Union<readonly [Number, String]>>;
chainingSeedMediaId: optionalKey<String>;
chainingSessionId: optionalKey<String>;
clientPosition: optionalKey<Union<readonly [Number, String]>>;
media: optionalKey<
Struct<
{
code: String;
id: String;
media_type: Number;
organic_tracking_token: optionalKey<String>;
pk: Union<readonly [String, Number]>;
taken_at: optionalKey<Number>;
user: optionalKey<
Struct<
{
id: optionalKey<String>;
pk: optionalKey<Union<readonly [(...), (...)]>>;
},
>,
>;
},
>,
>;
mediaPctWatched: optionalKey<Union<readonly [Number, String]>>;
pressSignals: optionalKey<
Struct<{ clientIpv4: String; ipv4ReceivedTimestamp: Number }>,
>;
rankingSessionId: optionalKey<String>;
storyRankingToken: optionalKey<String>;
},
> = ...
The viewer's input: the reel it opens on (absent when the bottom bar's tab opened it, which sends the recorded stream's first page), its chaining context and the caller's press signals.
How the viewer was reached is the edge's navigation source, not an input: the same definition is entered from the bottom bar (a tab switch, the chain restarting at
ClipsViewerFragment:clips_viewer_clips_tab) and pushed from a feed's reel or a link (ClipsViewerFragment:clips_viewerover the feed). The requests' module comes from that same navigation wire, so the input names no source of its own.