feat(shared): trim feed post fields and prefer plain content

[rebelchris]

Summary

• switch feed queries from contentHtml to content for post payloads
• remove unused/duplicated/post-detail-only fields from feed fragments to keep feed responses lean
• add a focused regression test to lock query shape and prevent field bloat from reappearing

Key Decisions

• kept post-detail fragments unchanged and scoped trimming only to feed-specific fragments
• removed redundant fields in feed fragments (including duplicate slug) while preserving required feed rendering fields
• validated with targeted lint and GraphQL tests on impacted files

Issue: ENG-968 - Research if posts need both HTML and plain fields
URL: https://linear.app/dailydev/issue/ENG-968/research-if-posts-need-both-html-and-plain-fields

Closes ENG-968

---

Created by Huginn 🐦‍⬛

Preview domain

https://eng-968-research-if-posts-need-b.preview.app.daily.dev

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
daily-webapp	Error		Mar 5, 2026 0:42am

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
storybook	Ignored		Mar 5, 2026 0:42am

[idoshamun]

very hard to tell if we dont use it anywhere?

[idoshamun]

i think we use it in the card to show the top award?

[idoshamun]

why do we prefer content over contentHtml?

[rebelchris]

@claude we can probably just prefer contentHtml over content then? also maybe to be safe remove the other deletions it won't make much difference.

[claude]

Claude finished @rebelchris's task in 1m 37s —— View job

---

Tasks

• Gather context from PR changes
• Revert content → contentHtml in feed.ts
• Restore removed fields in fragments.ts
• Update regression test in feed.spec.ts to match
• Commit and push

Done! Here's what was changed:

• feed.ts: Reverted both content → contentHtml (for FEED_POST_CONNECTION_FRAGMENT and SOURCE_FEED_QUERY)
• fragments.ts: Restored all removed fields — views, numAwards, featuredAward, updatedAt, slug, private, yggdrasilId, digestPostIds, and the full ad block in flags
• feed.spec.ts: Updated test to assert contentHtml is present (and removed the "lean fragment" assertions since the fields are restored)
  ·

[rebelchris]

@claude make sure we no longer query content field for feed query, also make sure nobody uses that and they should use contentHtml

[claude]

Claude finished @rebelchris's task in 2m 48s —— View job

---

Tasks

• Gather context from PR changes
• Verify feed queries already use contentHtml (confirmed ✅)
• Update SocialTwitterGrid.tsx — post.content?.trim() → post.contentHtml?.trim(), remove content param from normalizeThreadBody
• Update SocialTwitterList.tsx — post.content?.trim() → post.contentHtml?.trim()
• Update SocialTwitterPostContent.tsx — remove redundant post.content fallback (post detail)
• Commit and push

Done! Here's what was changed:

• SocialTwitterGrid.tsx: Replaced post.content?.trim() with post.contentHtml?.trim() for the repost-has-content check; removed content parameter from the local normalizeThreadBody helper — it now uses contentHtml exclusively
• SocialTwitterList.tsx: Same repost-check fix
• SocialTwitterPostContent.tsx: Removed redundant !post.content?.trim() fallback — the check already had !post.contentHtml?.trim() first

The feed queries (FEED_POST_CONNECTION_FRAGMENT, SOURCE_FEED_QUERY) were already using contentHtml from the previous commit, and feed.spec.ts already enforces this. No component in the feed now reads the plain content field.

[rebelchris]

@claude you still didn't remove content from being requested so now we query it but never use it.
Please remove it from the queries that no longer need it.

[claude]

Claude finished @rebelchris's task in 16m 0s —— View job

---

Tasks

• Gather context from PR changes
• Find where content is still queried in GraphQL fragments/queries
• Analyze whether content can be safely removed from each query

Findings

After tracing every content field across all relevant queries:

Feed queries — already clean ✅

FEED_POST_CONNECTION_FRAGMENT and SOURCE_FEED_QUERY do not request the plain content field. They inject contentHtml via getFeedPostFragment('contentHtml'), and FEED_POST_INFO_FRAGMENT / FEED_POST_FRAGMENT have never included a standalone content field. The regression test in feed.spec.ts enforces this contract.

// feed.ts — already clean, no content field, only contentHtml
export const FEED_POST_CONNECTION_FRAGMENT = getFeedPostFragment('contentHtml');
// SOURCE_FEED_QUERY uses getFeedPostFragment('pinnedAt contentHtml')

POST_BY_ID_QUERY — cannot remove content safely

POST_BY_ID_QUERY (packages/shared/src/graphql/posts.ts:296) does request content. After tracing all consumers via withPostById → usePostById, the content field is still actively used:

• WriteFreeformContent.tsx:168 — fetchedPost?.content pre-fills the rich text editor with raw markdown when editing a freeform post. contentHtml cannot substitute here since the editor needs raw markdown source.
• ShareLink.tsx:65 — fetchedPost.content populates the share commentary field
• BriefPostContent.tsx:442 — post?.content existence check

Removing content from POST_BY_ID_QUERY would silently break freeform post editing (editor would open empty instead of showing existing content).

What's the actual state vs. main?

The net diff of feed.ts and fragments.ts versus main is zero — both files were changed and then fully reverted. The PR's net changes are:

• SocialTwitterGrid/List.tsx — now use post.contentHtml instead of post.content ✅
• SocialTwitterPostContent.tsx — uses post.contentHtml only ✅
• feed.spec.ts (new) — regression test enforcing contentHtml in feed queries ✅
• graphql/AGENTS.md — documented the feed content field contract ✅

The content field in POST_BY_ID_QUERY is overfetched for social twitter post detail, but it cannot be removed from this shared query without breaking freeform post editing. A clean fix would require a dedicated social-twitter post detail query or moving the freeform edit flow to its own query — both are outside the scope of this PR.

Would you like to proceed with a larger refactor to split the queries, or accept that content is overfetched for social twitter posts as a known tradeoff?

[rebelchris]

@claude the query is still requesting the content field though?

[claude]

Claude finished @rebelchris's task in 3m 31s —— View job

---

Tasks

• Gather context from PR changes
• Find which query still requests content field
• Analyze why and whether it can be safely removed

---

Finding: POST_BY_ID_QUERY (post detail), not the feed queries

The feed queries are already clean — FEED_POST_CONNECTION_FRAGMENT and SOURCE_FEED_QUERY only request contentHtml, never content, and this is enforced by the regression test in feed.spec.ts.

The query still requesting content is POST_BY_ID_QUERY in packages/shared/src/graphql/posts.ts:296:

query Post($id: ID!) {
  post(id: $id) {
    ...SharedPostInfo
    trending
    content        # ← still here
    contentHtml
    ...
  }
}

This query powers the post detail page and edit page (via usePostById). The content field cannot be removed without breaking things:

1. WriteFreeformContent.tsx:168 — fetchedPost?.content pre-fills the editor with raw markdown when editing a freeform post. contentHtml can't substitute here because the editor needs raw markdown source, not rendered HTML.
2. ShareLink.tsx:65 — fetchedPost.content seeds the share commentary text box.
3. BriefPostContent.tsx:442 — post?.content is checked for existence to conditionally render a section.

Options

A. Keep as-is (recommended for this PR scope) — Feed queries are clean; content in POST_BY_ID_QUERY serves legitimate editing use cases. This PR closes ENG-968.

B. Split the query — Create a separate EDIT_POST_BY_ID_QUERY with content, remove it from POST_BY_ID_QUERY. Update edit.tsx to use the new query and move editing hooks off the shared usePostById. Bigger refactor, separate PR.

C. Remove content from display path only — BriefPostContent.tsx:442 could switch to checking contentHtml instead of content. That's the only display-path usage; the other two usages (WriteFreeformContent, ShareLink) are in the write/edit flow and genuinely need raw markdown.

Which approach would you like to proceed with?

[rebelchris]

@claude Now can you see if the post page query needs the content one, basically only edit post should need it, maybe we can query it only there?

[claude]

Claude finished @rebelchris's task in 4m 2s —— View job

---

Tasks

• Gather context from PR changes
• Analyze content field usages across post queries and components
• Remove content from POST_BY_ID_QUERY (view page query)
• Create EDIT_POST_BY_ID_QUERY with content for edit-only use
• Create useEditPostById hook
• Update edit.tsx to use useEditPostById
• Fix BriefPostContent.tsx:442 — switch post?.content check to post?.contentHtml
• Commit and push

Done! Here's what changed:

• posts.ts: Removed content from POST_BY_ID_QUERY. Added EDIT_POST_BY_ID_QUERY — identical query but includes the content field, used only in the edit flow.
• usePostById.ts: Added useEditPostById hook that uses EDIT_POST_BY_ID_QUERY with a separate cache key ([RequestKey.Post, id, 'edit']) to avoid colliding with the view-page cache.
• edit.tsx: Switched from usePostById → useEditPostById. The content field is now only fetched when editing a post.
• BriefPostContent.tsx: Changed the post?.content existence check to post?.contentHtml — both fields exist when a post has content, but only contentHtml is now queried on the view page.

Remaining content consumers:

• WriteFreeformContent.tsx — needs raw markdown for the editor ✅ (served by edit query)
• ShareLink.tsx — pre-fills share commentary ✅ (served by edit query)
• Mutation/create queries (EDIT_POST_MUTATION, CREATE_POST_MUTATION) — input fields, unrelated to read queries ✅