Repository navigation
Tags: tag-filtered feed (GET /api/messages?tag=) #29
Description
Activity
Implemented in #122 (branch
issue/29-tag-feed). Closing here — review and any follow-up happens on the PR.The "share the feed implementation rather than forking it" requirement drove the interesting part. Sharing the ViewModel and repository was easy; the Room cache was not. The main feed and a tag feed routinely contain the same message, and a message row cannot hold two positions — so with
feedOrderon the message, the second feed to load would have silently stolen rows from the first. Feed membership now lives in afeed_entry(feedKey, messageId, position)join table over shared message rows.The deep-link URL was established, not guessed.
/tag/lists,/tags/lists,/tags,/exploreand/trendingall 404, and/messagesis Direct Messages rather than the feed. The web's own tag chip (found in its JS chunk) links to"/?tag=".concat(encodeURIComponent(e)), andhttps://interlinedlist.com/?tag=listsdoes serve a filtered feed. So the canonical form ishttps://interlinedlist.com/?tag=<encoded>.One product decision for you: an Android intent filter cannot match on a query string, so catching
/?tag=…means registeringhttps://interlinedlist.com/— which also claims plain homepage links. They land on the app's normal start destination showing the same feed, so nothing breaks, but it is a wider claim than the feature strictly needs. Say if you would rather not claim it.
Part of #27 — Tags: tagging posts, autocomplete, trending and tag-filtered feeds
tagqueryparameter.
cursor-pagination work) rather than forking it.
Tests: tap → filtered query; paging works on the filtered feed.
Filed from the parity review of
feature/parity-wip@14d7795against interlinedlist.com (OpenAPI/api/openapi.json, 233 paths) and the public help centre.