Closed Southclaws closed 3 months ago
vercel[bot]
commented
3 months ago The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| storyden | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Aug 10, 2024 10:57am |
coderabbitai[bot]
commented
3 months ago Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
Southclaws
commented
3 months ago @coderabbitai review
coderabbitai[bot]
commented
3 months ago
A "Post" is just a piece of content, and Storyden will soon have Newsletters, Blogs and generic pages outside of the Library tree. Earlier in development however, after spinning out from the open.mp Forum codebase, there existed just Post and Thread (a Thread contains one or more Posts where the first Post is also the Thread itself.)
Because of this history, the schema reflected this in APIs under /posts and schema resources named Post*. However, the internal code has evolved a lot and settled on Post being higher in the information heirarchy with a Thread now being a kind of Post and Posts within a Thread being referred to as "Replies", which are just another kind of Post object.
This mental model is vastly simpler to both reason about and implement/structure. Post has been a top-level resource in the codebase structure for a while now, with Thread and Reply being descendants of this type. This change furthers that by providing a proper Post struct from which Threads and Replies can embed in their structs in order to contribute additional information for their specific use-cases.
In the cases of other resources that can reference Posts, these were originally (hackily) limited to Reply objects (which, confusingly could also represent Threads themselves, or at least the first Post within a Thread, which is the Thread's "root" post.) Collections, Links and Nodes can all reference Posts in various ways and building on the Datagraph rework (parent commit) this settles into a better abstraction for those data structures.
For example, a Collection can contain Library Nodes and Posts, and it does not need to hold any specific information about whether or not those Posts are Threads or Replies, they are just Posts. Post objects can more easily express whether they are roots or not but also, conveniently, simply provide their Root's ID, Title and Slug which is necessary for Collections and other aggregations to provide users with URLs and names to refer to them.
More work is required to properly differentiate between these for the UI and API levels, but this PR lays the groundwork. For example, a frontend implementation may want to provide a URL to a specific Post within a Thread, and for that we'd need to provide this information so that the frontend implementation can construct a URL that correctly leads to that specific post within a thread (a URL fragment will likely be the most common approach.)
However, this also plays into additional challenges I'd like to tackle around identifying resources. URN/URI strings could be useful here to express identities and also provide a universal abstraction over IDs, slugs, handles, etc. (frequently referred to as "Marks" in the codebase, such as ThreadMark to identify the combination of the Thread's slug and ID which provides a URL-friendly string that's both unique and also contains a slugified version of the Thread's title)