Social Posts

This document covers the current implementation of the Posts screen in apps/frontend.

Status

• Route: /posts
• Route wrapper: apps/frontend/src/routes/posts/SocialPostsRoute.tsx
• Feature page: apps/frontend/src/features/posts/components/PostsPage.tsx
• Storybook: apps/frontend/src/features/posts/components/PostsPage.stories.tsx
• Tests: apps/frontend/src/features/posts/components/PostsPage.test.tsx

UX Model

The page uses a list-and-editor layout:

• Left: search + filters + post queue cards
• Right: editable post form (content, platforms, mode, schedule)
• Header actions: refresh and create draft

Primary behavior is manual posting:

• "Copy & Post" opens native platform compose intents.
• Manual publish is recorded with /api/social-posts/:id/manual-record.
• Direct network auto-publish remains future work (#210).

Data and Persistence

• If auth_token is present, data syncs with backend.
• Without token, page falls back to local demo seed data for safe local development.
• Selected post and editor baseline are tracked to support dirty-state save/revert behavior.

API Usage

Frontend calls:

• GET /api/social-posts
• POST /api/social-posts
• PUT /api/social-posts/:id
• DELETE /api/social-posts/:id
• POST /api/social-posts/batch-schedule
• POST /api/social-posts/:id/manual-record

Implementation Notes

• Supported platform enum in frontend: linkedin | twitter | instagram | facebook.
• editor.mode drives save behavior:
  • draft -> saved as draft
  • schedule -> scheduled timestamp required
• Status chips and list selection styling should always communicate active/selected state clearly.

Migration Guardrails

• Do not reintroduce legacy /social-posts-v2 route in docs as the primary path.
• Keep API payload mapping helpers near the page (fromBackend, toInputDateTime) to avoid drift.
• Any future publishing behavior change must update both client + internal docs in the same PR.