getPreloadedPageSortType assumes exactly one preloaded sort per record

[Rinse12]

Summary

getPreloadedPageSortType in src/lib/page-sorts.ts assumes a community record carries exactly one preloaded sort. That is true today, but it is an implementation detail of pkc-js rather than a protocol guarantee, and multiple preloaded sorts are a plausible future direction.

Current behaviour

const getPreloadedPageSortType = (record) => {
  const preloadedSortType = Object.keys(record?.pages || {}).find(Boolean);
  return preloadedSortType || getAvailablePageSortTypes(record)[0];
};

Two positional assumptions:

1. Object.keys(pages).find(Boolean) takes the first key of pages. Today pages has exactly one key because pkc-js does pick(generatedPosts.pages, [preloadedPostsPages]) before publishing. If it ever preloads two sorts, this silently picks one of them with no signal to the caller.
2. The fallback getAvailablePageSortTypes(record)[0] takes the first key of pageCids when pages is empty. pages genuinely is empty in a real pkc-js case: generatePostPages and generateReplyPages return pages: {} when the preloaded chunk exceeds the size budget and preloading is disabled. The value is deterministic in practice, since records are serialised with sorted keys before publishing, but it is an alphabetical accident rather than a preloaded sort. In that state there is no preloaded sort at all, and reporting one is a guess.

Why it matters

pkcprotocol/pkc-js#73 makes the generated sort set operator-configurable. Multiple preloaded sorts are explicitly out of scope there, but the design commits to not foreclosing them, so nothing in pkc-js will bake in "exactly one". This helper does bake it in, and it is now the default sort resolution path for both feeds and replies, so a future change on the pkc-js side would surface here as a silently wrong default sort rather than an error.

Proposed direction

1. Return the full set of preloaded sorts rather than one, and let callers decide, e.g. getPreloadedPostSortTypes(community): string[]. Keep a singular helper if convenient, but define it in terms of the plural one.
2. Distinguish "no preloaded page exists" from "here is the preloaded sort". When pages is empty, say so, rather than falling back to the first pageCids key. Callers that just want something loadable can ask for that explicitly.
3. Separately: resolvePostSortType currently returns undefined for three different situations, and getPreloadedPosts in src/stores/feeds/utils.ts does if (!resolvedSortType) return; for all of them. The three are: the community has not loaded yet, the requested sort is not published by this community, and nothing was requested and nothing is available. #86 asked for the unavailable case to be observable to the app. An app can currently disambiguate by calling the exported getAvailablePostSortTypes itself, but the hook gives no signal, so a tab for an unpublished sort renders identically to one still loading.

Related

• Follows #86 and #91.

[Rinse12]

Update: preloadedPostSorts / preloadedReplySorts in pkcprotocol/pkc-js#73 are now arrays, so a record can embed the first page of more than one sort. This is no longer a speculative future concern.

Concretely, getPreloadedPageSortType returning a single sort taken from Object.keys(pages).find(Boolean) will silently pick one of several preloaded sorts. The helper should return the full set, with the first published key as the default, and callers should pick from it rather than receiving one value.

The design also drops the "no preloaded sort at all" fallback ambiguity noted above: with arrays, pages: {} means every preloaded sort failed or overflowed the budget, which is a distinct state worth surfacing rather than papering over with the first pageCids key.