The Explore tab (the bottom bar's search entry): ExploreFragment, module
explore_popular, reached from the feed's search tab (main_search). It
shows a search field over a grid of posts.
Wire: the enter sends the playback configuration (clips/autoplay_configs/) at
once, waits the app's own fragment settle, then asks for the recent searches,
the search null state and — when the process's stash holds no fresh answer
for the tab's surfaces — the search surface's quick promotions, as the
the app's tab does; the recent request goes out while the feed is still in
front (fbsearch/recent_searches reports the feed's
endpoint, the null state reports the tab's), so the enter yields the
navigation between them. When the account's popular-keyword cache is more
than a day old the tab also refreshes it, right after the configuration. The tab's quick-promotion slot (EXPLORE) fires
its four screen-load triggers once the fragment is loaded — after the
autoplay configuration, which the app sends without them — and they run
over the fragment's requests and the slot's batch, so the recent searches and
the null state carry 332008142,332009826,332019700,332020325 exactly as
the app's do. The grid itself is not requested by the tab:
the app prefetches it at launch (discover/topical_explore with
is_prefetch=true) and the tab tap
sends no grid request at all, so the grid is the
process's launch prefetch, not this screen's data. The launch burst does not
model that prefetch yet, so the screen's data is what its own enter fetches:
the recent accounts.
openSearchInput opens the search field with the recent accounts and sends
nothing (the 451 app's field open has no request of its own).
Confirmed on Android 451: the feed's search tab opened, then the field; and
the tab, the field and its first recent account opened into a profile.
Screenshot: none; the tab's grid shows other accounts' posts, which are not
the test accounts' to publish. The screen ships without one.
The Explore tab (the bottom bar's search entry):
ExploreFragment, moduleexplore_popular, reached from the feed's search tab (main_search). It shows a search field over a grid of posts.Wire: the enter sends the playback configuration (
clips/autoplay_configs/) at once, waits the app's own fragment settle, then asks for the recent searches, the search null state and — when the process's stash holds no fresh answer for the tab's surfaces — the search surface's quick promotions, as the the app's tab does; the recent request goes out while the feed is still in front (fbsearch/recent_searchesreports the feed's endpoint, the null state reports the tab's), so the enter yields the navigation between them. When the account's popular-keyword cache is more than a day old the tab also refreshes it, right after the configuration. The tab's quick-promotion slot (EXPLORE) fires its four screen-load triggers once the fragment is loaded — after the autoplay configuration, which the app sends without them — and they run over the fragment's requests and the slot's batch, so the recent searches and the null state carry332008142,332009826,332019700,332020325exactly as the app's do. The grid itself is not requested by the tab: the app prefetches it at launch (discover/topical_explorewithis_prefetch=true) and the tab tap sends no grid request at all, so the grid is the process's launch prefetch, not this screen's data. The launch burst does not model that prefetch yet, so the screen's data is what its own enter fetches: the recent accounts.openSearchInputopens the search field with the recent accounts and sends nothing (the 451 app's field open has no request of its own).Confirmed on Android 451: the feed's search tab opened, then the field; and the tab, the field and its first recent account opened into a profile.
Screenshot: none; the tab's grid shows other accounts' posts, which are not the test accounts' to publish. The screen ships without one.
Guide: Explore tab