Skip to content

feat!: SocialPlatformsResponse becomes ordered { platforms: SocialPlatformConfig[] }#6

Merged
chubes4 merged 1 commit into
mainfrom
platforms-array-contract
Apr 26, 2026
Merged

feat!: SocialPlatformsResponse becomes ordered { platforms: SocialPlatformConfig[] }#6
chubes4 merged 1 commit into
mainfrom
platforms-array-contract

Conversation

@chubes4
Copy link
Copy Markdown
Member

@chubes4 chubes4 commented Apr 26, 2026

Summary

Mirrors the breaking REST contract change in data-machine-socials#131. The /platforms endpoint now returns an ordered array under a { platforms: [...] } envelope with slug and canonical capabilities always present on every entry. This PR updates the typed wrapper to match.

Changes

Before

export interface SocialPlatformConfig {
  label: string;
  authenticated: boolean;
  username: string | null;
  // ... no slug, no capabilities
}

export type SocialPlatformsResponse = Record<string, SocialPlatformConfig>;

After

export interface SocialPlatformCapability {
  slug: string;
  label: string;
}

export interface SocialPlatformConfig {
  slug: string;                              // ← now required
  label: string;
  type: string;                              // ← now required
  authenticated: boolean;
  username: string | null;
  capabilities: SocialPlatformCapability[];  // ← now required, canonical shape
  // ... rest of fields unchanged
}

export interface SocialPlatformsResponse {
  platforms: SocialPlatformConfig[];         // ← array, ordered
}

SocialsResource.getPlatforms() signature is unchanged on disk (Promise<SocialPlatformsResponse>); only the underlying type shape changed.

Why

  • platforms array — server controls display order (authenticated-first then A-Z), clients render in iteration order. No more relying on JS object key insertion order.
  • slug always present — clients no longer reconstruct it from object keys.
  • Canonical capabilities shape — kills the string[] legacy fallback in client code (server-side normalize_capabilities handles legacy handler output before serialization).

Coordinated rollout

This is PR B of a 3-PR cluster:

  1. data-machine-socials#131 — REST contract
  2. B (this PR) — typed wrapper
  3. extrachill-studio (next) — consumer

Studio + any other api-client consumer will break against the new server response until C lands. Order: A → B → C, deploy in same order.

Test plan

  • npx tsc --noEmit clean
  • npm run build clean (CJS + ESM + DTS bundles)
  • ⏳ Studio sidebar regression check after PR C deploys

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant