@stapel/listings-react 0.1.0

package/src/model/features.ts

@@ -0,0 +1,122 @@
+/**
+ * The stored DAO projection → something `@stapel/attributes-react` can draw.
+ *
+ * A listing carries its attribute values THREE times, all of them DAO lists:
+ * `features` (everything, ordered), `features_title` (the ones flagged for
+ * the title line) and `features_badges` (the ones flagged for the card). A
+ * DAO is the value together with the display configuration its type needs —
+ * `prefix`, `precision`, `trueLabel`, `unitType`, … all inline beside
+ * `value` — which is the single most useful property of this contract:
+ *
+ *   **a card can render its badges without ever fetching the category.**
+ *
+ * `formatFeatureValue` wants a `(FeatureDef, FeatureValueDto)` pair, so this
+ * module splits a DAO back into one. The split is mechanical, and it is
+ * written down once here rather than at each of the three call sites.
+ *
+ * ── Where the config comes from, and why the whole row is handed over ──────
+ *
+ * `FeatureConfig` has an index signature, so passing the DAO itself as the
+ * config costs nothing and loses nothing: the type-specific keys are already
+ * at the top level of the row, and the four presentation flags (`name`,
+ * `order`, `title`, `badge`) are simply ignored by every formatter. Copying a
+ * hand-picked subset instead would be a list to keep in step with ten types.
+ *
+ * ── What a DAO does NOT carry ──────────────────────────────────────────────
+ *
+ * `select`'s `options`. `normalize_to_dao` stores the chosen VALUES, not the
+ * option table, so `formatFeatureValue` falls back to the raw option value —
+ * which is a translation KEY when the config is translatable (the default),
+ * so a host whose bundle carries the catalogue's option copy still reads a
+ * word. A host whose bundle does not sees the key, on purpose: a visible
+ * `option.condition.used` gets fixed, an invented "Used" ships wrong.
+ */
+import type { FeatureDef, FeatureValueDto } from "@stapel/attributes-react";
+import type { ListingFeatureDao, ListingFeatureView } from "../api/types.js";
+
+/** Keys that belong to the DAO envelope rather than to the type's config. */
+const ENVELOPE = new Set(["slug", "value", "name", "order", "title", "badge"]);
+
+/**
+ * One DAO row → the definition/value pair the display half consumes.
+ *
+ * `undefined` for a row with no `slug`: the stored projection always injects
+ * one (`build_features_list`: `{**dao, "slug": slug}`), so a row without it
+ * is a malformed record, and a synthesized index would key a badge to a
+ * position that changes whenever the category does.
+ */
+export function featureFromDao(
+  dao: ListingFeatureDao
+): ListingFeatureView | undefined {
+  if (typeof dao.slug !== "string" || dao.slug.length === 0) return undefined;
+
+  const config: Record<string, unknown> = {};
+  for (const [key, value] of Object.entries(dao)) {
+    if (!ENVELOPE.has(key)) config[key] = value;
+  }
+
+  const feature: FeatureDef = {
+    slug: dao.slug,
+    config,
+    name: dao.name ?? null,
+    ...(dao.translate !== undefined ? { translate: dao.translate } : {}),
+  };
+
+  const value: FeatureValueDto | undefined =
+    typeof dao.type === "string" && dao.type.length > 0
+      ? { type: dao.type, value: dao.value }
+      : undefined;
+
+  return { feature, value };
+}
+
+/** A stored projection → the pairs a display component iterates. Malformed
+ * rows are dropped HERE, in one place, and counted by {@link
+ * unreadableFeatureCount} so a skin can say how many rather than pretend the
+ * listing had fewer attributes. */
+export function featuresFromDaoList(
+  daos: readonly ListingFeatureDao[] | null | undefined
+): readonly ListingFeatureView[] {
+  const out: ListingFeatureView[] = [];
+  for (const dao of daos ?? []) {
+    const view = featureFromDao(dao);
+    if (view !== undefined) out.push(view);
+  }
+  return out;
+}
+
+/** How many rows of a stored projection this build could not key. */
+export function unreadableFeatureCount(
+  daos: readonly ListingFeatureDao[] | null | undefined
+): number {
+  return (daos ?? []).length - featuresFromDaoList(daos).length;
+}
+
+/**
+ * A stored projection → the `{slug: {type, value}}` envelope, which is what
+ * a composer reopening a PUBLISHED listing needs: `draftValuesFromDetail`
+ * seeds its editors from the published values, and the published values live
+ * only in the DAO list.
+ */
+export function featuresDtoFromDaoList(
+  daos: readonly ListingFeatureDao[] | null | undefined
+): Readonly<Record<string, FeatureValueDto>> {
+  const out: Record<string, FeatureValueDto> = {};
+  for (const view of featuresFromDaoList(daos)) {
+    if (view.value !== undefined) out[view.feature.slug] = view.value;
+  }
+  return out;
+}
+
+/**
+ * The `features` field of a detail response, typed.
+ *
+ * The generated `FeatureDao` union is unusable (the discriminator defect —
+ * see `api/types.ts`), and `features` is a `JSONField` on the serializer, so
+ * this cast is the boundary between "the schema's description" and "the row
+ * the JSONField actually emitted". It lives in ONE function so there is one
+ * place to change when upstream fixes the mapping.
+ */
+export function asFeatureDaoList(value: unknown): readonly ListingFeatureDao[] {
+  return Array.isArray(value) ? (value as readonly ListingFeatureDao[]) : [];
+}

package/src/model/mineSource.ts

@@ -0,0 +1,55 @@
+/**
+ * THE GAP: stapel-listings cannot list a person their own listings.
+ *
+ * This is the one place in the pair where a contract is missing rather than
+ * awkward, so it gets its own module and its own name.
+ *
+ * `GET /listings/` answers `qs.published()` and takes no owner parameter
+ * (`views.ListingViewSet.get_queryset`): it returns the whole marketplace's
+ * shop window and can be narrowed to nobody. The only owner-scoped reads in
+ * the module are `my/counters` (three integers) and `my/favorites`. So a
+ * seller's own DRAFTS are unreachable by any call this contract offers — and
+ * drafts are not indexed either, so routing around it through
+ * `@stapel/search-react`'s `owner=` would return the published subset and
+ * quietly call it "everything".
+ *
+ * The storefront spec assumed `GET /listings/` was "for mine" (§4.1). It is
+ * not, and this pair records the gap rather than papering over it.
+ *
+ * Two upstream asks, in preference order:
+ *  1. an `?owner=me` filter (or a `my/listings` action) on the list endpoint,
+ *     with the same `IDAnchorPagination` envelope the other two use;
+ *  2. failing that, a `status` filter on it, so at least the published subset
+ *     can be narrowed without a search module.
+ *
+ * Until then a host injects a {@link MyListingsSource} and the dashboard
+ * works completely; without one it shows the real counters and NAMES the
+ * absence, because "we cannot ask" and "you have no listings" are different
+ * sentences.
+ */
+import { StapelApiError } from "@stapel/core";
+import type { ListingPageParams, PaginatedListingCards } from "../api/types.js";
+import type { MyListingsTab } from "./status.js";
+import { LISTINGS_I18N_KEYS } from "../i18n/keys.js";
+
+/** One page of the caller's own listings, however the host can get them. */
+export type MyListingsSource = (args: {
+  readonly tab: MyListingsTab;
+  readonly page: ListingPageParams;
+  readonly signal?: AbortSignal;
+}) => Promise<PaginatedListingCards>;
+
+/**
+ * The error a dashboard without a source reports.
+ *
+ * `status: 0` on purpose: this is a fact about the deployment's wiring, not
+ * something a server said, and a client-side refusal must never be
+ * indistinguishable from one that came over the wire.
+ */
+export const MY_LISTINGS_SOURCE_MISSING: StapelApiError = new StapelApiError({
+  code: LISTINGS_I18N_KEYS.mineSourceMissing,
+  message:
+    "No MyListingsSource was supplied, and stapel-listings has no " +
+    "owner-scoped list endpoint to fall back on.",
+  status: 0,
+});

package/src/model/mutations.ts

@@ -0,0 +1,224 @@
+import { useMutation, useQueryClient } from "@tanstack/react-query";
+import type { QueryClient, UseMutationResult } from "@tanstack/react-query";
+import type { StapelApiError } from "@stapel/core";
+import type {
+  DeleteResponse,
+  FavoriteToggleResponse,
+  ListingActionResponse,
+  ListingDraft,
+  ListingDraftPatch,
+  PublishResponse,
+} from "../api/types.js";
+import { useListingsApi } from "./context.js";
+import { listingsQueryKeys } from "./queryKeys.js";
+
+/**
+ * Every write in the module, each one saying what it invalidates and why.
+ *
+ * ── The listing id is a VARIABLE, not a hook argument ──────────────────────
+ *
+ * Every mutation here takes its id in the mutation's variables rather than in
+ * the hook's closure, and that is a correctness decision rather than a style
+ * one. The composer creates the draft row and saves into it IN THE SAME user
+ * gesture: an id-bound hook would still be holding the id from the render
+ * before the create, so the save would go to the wrong path (or to none). A
+ * variable is read at call time, which is the only time the id is known.
+ *
+ * ── The invalidation rule ──────────────────────────────────────────────────
+ *
+ * A write that can move `status` or `moderation_status` invalidates the
+ * DETAIL, the STATUS probe and the COUNTERS — the counters because their
+ * three tabs are defined by status sets (`views.my_counters`), so a publish
+ * silently moves a row from "drafts" to "active" and a dashboard that did not
+ * refetch would show the old number beside the new row.
+ *
+ * Nothing here is optimistic except the favourite toggle, and that exception
+ * is argued at its own hook.
+ */
+
+/** Everything a status-moving write must freshen. */
+function invalidateListing(queryClient: QueryClient, id: number): void {
+  void queryClient.invalidateQueries({ queryKey: listingsQueryKeys.detail(id) });
+  void queryClient.invalidateQueries({ queryKey: listingsQueryKeys.status(id) });
+  void queryClient.invalidateQueries({
+    queryKey: listingsQueryKeys.myCounters(),
+  });
+  void queryClient.invalidateQueries({
+    queryKey: listingsQueryKeys.validateDraft(id),
+  });
+}
+
+/** Start a draft. The server forces `owner` and `status=draft`. */
+export function useCreateDraft(): UseMutationResult<
+  ListingDraft,
+  StapelApiError,
+  ListingDraftPatch
+> {
+  const api = useListingsApi();
+  const queryClient = useQueryClient();
+  return useMutation({
+    mutationFn: (body: ListingDraftPatch) => api.createDraft(body),
+    retry: false,
+    onSuccess: () => {
+      void queryClient.invalidateQueries({
+        queryKey: listingsQueryKeys.myCounters(),
+      });
+    },
+  });
+}
+
+/** What a `save-draft` write carries. */
+export interface SaveDraftInput {
+  readonly id: number;
+  readonly body: ListingDraftPatch;
+}
+
+/**
+ * Persist draft fields. Always partial — send what the form holds.
+ *
+ * The validate-draft entry is invalidated rather than written: the saved row
+ * comes back, but it carries no verdict, and a stale verdict beside fresh
+ * content is the one combination a composer must never show.
+ */
+export function useSaveDraft(): UseMutationResult<
+  ListingDraft,
+  StapelApiError,
+  SaveDraftInput
+> {
+  const api = useListingsApi();
+  const queryClient = useQueryClient();
+  return useMutation({
+    mutationFn: (input: SaveDraftInput) => api.saveDraft(input.id, input.body),
+    retry: false,
+    onSuccess: (_data, input) => {
+      invalidateListing(queryClient, input.id);
+    },
+  });
+}
+
+/**
+ * Promote the draft.
+ *
+ * `retry: false` — the 400 here is a VERDICT about the content (a bare
+ * `ValidationBatchResult` body, see `model/validation.ts`), and repeating a
+ * verdict three times only delays the moment the composer can lay it on the
+ * controls.
+ */
+export function usePublishListing(): UseMutationResult<
+  PublishResponse,
+  StapelApiError,
+  number
+> {
+  const api = useListingsApi();
+  const queryClient = useQueryClient();
+  return useMutation({
+    mutationFn: (id: number) => api.publish(id),
+    retry: false,
+    onSuccess: (_data, id) => {
+      invalidateListing(queryClient, id);
+    },
+  });
+}
+
+/** Move to ARCHIVED. 409 `error.409.invalid_listing_transition` carries
+ * `params.from_status`, which is what turns the refusal into a sentence. */
+export function useArchiveListing(): UseMutationResult<
+  ListingActionResponse,
+  StapelApiError,
+  number
+> {
+  const api = useListingsApi();
+  const queryClient = useQueryClient();
+  return useMutation({
+    mutationFn: (id: number) => api.archive(id),
+    retry: false,
+    onSuccess: (_data, id) => {
+      invalidateListing(queryClient, id);
+    },
+  });
+}
+
+/** Mark SOLD. Same 409 contract as {@link useArchiveListing}. */
+export function useCompleteListing(): UseMutationResult<
+  ListingActionResponse,
+  StapelApiError,
+  number
+> {
+  const api = useListingsApi();
+  const queryClient = useQueryClient();
+  return useMutation({
+    mutationFn: (id: number) => api.complete(id),
+    retry: false,
+    onSuccess: (_data, id) => {
+      invalidateListing(queryClient, id);
+    },
+  });
+}
+
+/** Soft-delete. Refused with `error.409.listing_cannot_delete_active` while
+ * the listing is PUBLISHED or PENDING. */
+export function useDeleteListing(): UseMutationResult<
+  DeleteResponse,
+  StapelApiError,
+  number
+> {
+  const api = useListingsApi();
+  const queryClient = useQueryClient();
+  return useMutation({
+    mutationFn: (id: number) => api.remove(id),
+    retry: false,
+    onSuccess: (_data, id) => {
+      invalidateListing(queryClient, id);
+      void queryClient.invalidateQueries({ queryKey: listingsQueryKeys.all });
+    },
+  });
+}
+
+/** What a favourite toggle carries: the id and the state it should END in. */
+export interface FavoriteInput {
+  readonly id: number;
+  readonly favorited: boolean;
+}
+
+/**
+ * Favourite / un-favourite, as ONE mutation over the intended next state.
+ *
+ * Two endpoints, one intent — and modelling it as two hooks would let a
+ * caller call the wrong one for the state it is in. The server is idempotent
+ * on both sides (`get_or_create` / `filter().delete()`), so a double-click
+ * cannot desynchronise anything.
+ *
+ * This is the pair's ONE write whose next state the client may predict, and
+ * the reason is that the truth is a single boolean the caller already holds.
+ * Everything else here moves a LIFECYCLE whose next state is the server's to
+ * decide — guessing `pending` versus `published` after a publish would be
+ * inventing the very verdict the pair exists to report faithfully.
+ *
+ * The invalidation reaches the favourites LIST as well as the row: a heart
+ * turned off on the favourites page must remove the card, not leave a hollow
+ * one behind.
+ */
+export function useFavoriteListing(): UseMutationResult<
+  FavoriteToggleResponse,
+  StapelApiError,
+  FavoriteInput
+> {
+  const api = useListingsApi();
+  const queryClient = useQueryClient();
+  return useMutation({
+    mutationFn: (input: FavoriteInput) =>
+      input.favorited ? api.favorite(input.id) : api.unfavorite(input.id),
+    retry: false,
+    onSettled: (_data, _error, input) => {
+      void queryClient.invalidateQueries({
+        queryKey: listingsQueryKeys.detail(input.id),
+      });
+      void queryClient.invalidateQueries({
+        queryKey: listingsQueryKeys.allFavorites(),
+      });
+      void queryClient.invalidateQueries({
+        queryKey: listingsQueryKeys.allLists(),
+      });
+    },
+  });
+}

package/src/model/queries.ts

@@ -0,0 +1,150 @@
+import { keepPreviousData, useQuery } from "@tanstack/react-query";
+import type { UseQueryResult } from "@tanstack/react-query";
+import { useActiveSessionReady } from "@stapel/core";
+import type { StapelApiError } from "@stapel/core";
+import type { ValidationBatchResult } from "@stapel/attributes-react";
+import type {
+  ListingDetail,
+  ListingPageParams,
+  ListingStatusInfo,
+  MyCounters,
+  PaginatedListingCards,
+} from "../api/types.js";
+import { useListingsApi } from "./context.js";
+import { listingsQueryKeys, pageKey } from "./queryKeys.js";
+
+/**
+ * Read hooks over the listings API (frontend-standard §2). Keys are
+ * namespaced (see `listingsQueryKeys`).
+ *
+ * ── Two gating regimes in one module, and the line between them ────────────
+ *
+ * `useListing` / `useListingStatus` / `useListingCards` call
+ * `IsAuthenticatedOrReadOnly` and `AllowAny` endpoints: a visitor reads them
+ * with no session at all, so gating on `useActiveSessionReady` would make a
+ * shop window wait for a login bootstrap it has no stake in. Core's own doc
+ * comment carves out exactly this case.
+ *
+ * `useMyCounters` / `useMyFavorites` / `useValidateDraft` are
+ * `IsAuthenticated` and DO gate: firing them before the session substrate has
+ * settled produces a 401 that means "we asked too early", which is
+ * indistinguishable on screen from "you are signed out".
+ */
+
+/**
+ * One listing in full.
+ *
+ * `retry: false` on purpose. The failures here are verdicts about the
+ * request: a 404 for a listing that is gone, a 403 for one that is not
+ * yours. Retrying a 404 three times only delays the moment the page can say
+ * which it was — and for a soft-deleted listing, `useListingStatus` is the
+ * read that can actually explain it (see `headless/ListingDetail.tsx`).
+ */
+export function useListing(
+  id: number | undefined,
+  options?: { readonly enabled?: boolean }
+): UseQueryResult<ListingDetail, StapelApiError> {
+  const api = useListingsApi();
+  return useQuery({
+    queryKey: listingsQueryKeys.detail(id ?? -1),
+    queryFn: ({ signal }) => api.retrieve(id as number, { signal }),
+    enabled: (options?.enabled ?? true) && id !== undefined,
+    retry: false,
+  });
+}
+
+/**
+ * The status probe — both axes plus `is_deleted`, for ANY listing id.
+ *
+ * The one read that survives a soft delete (`Listing.all_objects`), which is
+ * why a detail page runs it beside the detail rather than only after a
+ * failure: "this listing was removed" is a sentence, and a bare 404 is not.
+ */
+export function useListingStatus(
+  id: number | undefined,
+  options?: { readonly enabled?: boolean }
+): UseQueryResult<ListingStatusInfo, StapelApiError> {
+  const api = useListingsApi();
+  return useQuery({
+    queryKey: listingsQueryKeys.status(id ?? -1),
+    queryFn: ({ signal }) => api.status(id as number, { signal }),
+    enabled: (options?.enabled ?? true) && id !== undefined,
+    retry: false,
+  });
+}
+
+/**
+ * A keyset page of PUBLISHED cards.
+ *
+ * `keepPreviousData`: paging a grid that blanks between pages reads as a
+ * failure, and the previous page is still a true answer about the previous
+ * cursor. The FIRST load has nothing to keep and is `loading`; a failure is
+ * still `failed` rather than stale rows pretending to be current.
+ */
+export function useListingCards(
+  params?: ListingPageParams,
+  options?: { readonly enabled?: boolean }
+): UseQueryResult<PaginatedListingCards, StapelApiError> {
+  const api = useListingsApi();
+  return useQuery({
+    queryKey: listingsQueryKeys.list(pageKey(params)),
+    queryFn: ({ signal }) => api.list(params, { signal }),
+    enabled: options?.enabled ?? true,
+    placeholderData: keepPreviousData,
+    retry: false,
+  });
+}
+
+/** The dashboard's three counts. Session-gated. */
+export function useMyCounters(options?: {
+  readonly enabled?: boolean;
+}): UseQueryResult<MyCounters, StapelApiError> {
+  const api = useListingsApi();
+  const sessionReady = useActiveSessionReady();
+  return useQuery({
+    queryKey: listingsQueryKeys.myCounters(),
+    queryFn: ({ signal }) => api.myCounters({ signal }),
+    enabled: (options?.enabled ?? true) && sessionReady,
+    retry: false,
+  });
+}
+
+/** A keyset page of the caller's favourites. Session-gated. */
+export function useMyFavorites(
+  params?: ListingPageParams,
+  options?: { readonly enabled?: boolean }
+): UseQueryResult<PaginatedListingCards, StapelApiError> {
+  const api = useListingsApi();
+  const sessionReady = useActiveSessionReady();
+  return useQuery({
+    queryKey: listingsQueryKeys.myFavorites(pageKey(params)),
+    queryFn: ({ signal }) => api.myFavorites(params, { signal }),
+    enabled: (options?.enabled ?? true) && sessionReady,
+    placeholderData: keepPreviousData,
+    retry: false,
+  });
+}
+
+/**
+ * What publishing WOULD say, without publishing.
+ *
+ * Disabled by default: it is a round trip per call and the composer's own
+ * mirror answers the same question for free most of the time. A composer
+ * turns it on when the person asks ("check my listing") and after a save, so
+ * the SERVER's opinion of the saved draft is what the button reports —
+ * `staleTime: 0` because the draft is exactly the thing that just moved.
+ */
+export function useValidateDraft(
+  id: number | undefined,
+  options?: { readonly enabled?: boolean }
+): UseQueryResult<ValidationBatchResult, StapelApiError> {
+  const api = useListingsApi();
+  const sessionReady = useActiveSessionReady();
+  return useQuery({
+    queryKey: listingsQueryKeys.validateDraft(id ?? -1),
+    queryFn: ({ signal }) => api.validateDraft(id as number, { signal }),
+    enabled: (options?.enabled ?? false) && id !== undefined && sessionReady,
+    staleTime: 0,
+    retry: false,
+  });
+}

package/src/model/queryKeys.ts

@@ -0,0 +1,76 @@
+/**
+ * Namespaced TanStack Query keys (frontend-standard §2 — namespaced keys).
+ * Everything under the `"listings"` root so a host can invalidate the whole
+ * module or match a single read. Explicit tuple return types satisfy
+ * `--isolatedDeclarations`.
+ *
+ * THE KEY IS THE REQUEST for the paginated reads: a page is keyed on the very
+ * parameter object the client is handed, normalized so that "no cursor" and
+ * "an explicitly undefined cursor" cannot cache twice. Two states that
+ * produce the same request therefore share a cache entry, and one that
+ * produces a different request cannot silently reuse a page — the stale-page
+ * bug (new filter, cached rows) is unwritable rather than merely avoided.
+ */
+import type { ListingPageParams } from "../api/types.js";
+
+/** The normalized page cursor a list read is keyed on. */
+export interface ListingPageKey {
+  readonly anchor: string | null;
+  readonly direction: string | null;
+  readonly limit: number | null;
+}
+
+/** Normalize a page's parameters into its key. Exported because a test that
+ * asserts "these two states hit one cache entry" must build the key the same
+ * way the hook does. */
+export function pageKey(params?: ListingPageParams): ListingPageKey {
+  return {
+    anchor: params?.anchor ?? null,
+    direction: params?.direction ?? null,
+    limit: params?.limit ?? null,
+  };
+}
+
+const ROOT = "listings" as const;
+
+export const listingsQueryKeys: {
+  readonly all: readonly ["listings"];
+  /** The published card list. */
+  list(page: ListingPageKey): readonly ["listings", "list", ListingPageKey];
+  /** One listing in full. */
+  detail(id: number): readonly ["listings", "detail", number];
+  /** The AllowAny status probe — a SEPARATE entry from the detail on purpose:
+   * it answers for a soft-deleted listing the detail 404s on, so caching them
+   * together would let a 404 evict the one read that can explain it. */
+  status(id: number): readonly ["listings", "status", number];
+  /** The dashboard's three counts. */
+  myCounters(): readonly ["listings", "my", "counters"];
+  /** The caller's favourites, one keyset page. */
+  myFavorites(
+    page: ListingPageKey
+  ): readonly ["listings", "my", "favorites", ListingPageKey];
+  /** The owner's own rows, per tab — see `headless/MyListings.tsx` for why
+   * this read goes through an injected source. */
+  mine(
+    tab: string,
+    page: ListingPageKey
+  ): readonly ["listings", "my", "listings", string, ListingPageKey];
+  /** `GET /{pk}/validate-draft/` — the dry run of a publish. */
+  validateDraft(id: number): readonly ["listings", "validate-draft", number];
+  /** Every favourites PAGE, for an invalidation after a toggle — the cursor
+   * is not known at the write, so the prefix is what a write can target. */
+  allFavorites(): readonly ["listings", "my", "favorites"];
+  /** Every published-card PAGE, same reason. */
+  allLists(): readonly ["listings", "list"];
+} = {
+  all: [ROOT],
+  list: (page) => [ROOT, "list", page],
+  detail: (id) => [ROOT, "detail", id],
+  status: (id) => [ROOT, "status", id],
+  myCounters: () => [ROOT, "my", "counters"],
+  myFavorites: (page) => [ROOT, "my", "favorites", page],
+  mine: (tab, page) => [ROOT, "my", "listings", tab, page],
+  validateDraft: (id) => [ROOT, "validate-draft", id],
+  allFavorites: () => [ROOT, "my", "favorites"],
+  allLists: () => [ROOT, "list"],
+};