Build journal: article pages and the limits of an API

The home page was complete enough to navigate, so the next screen was the article detail view. The first version was deliberately a skeleton: a reaction area, the article body, the author information, and a place for related reading. The structure gave the feature a shape before the styling added weight to it.

Working with the API instead of against it

The public article endpoint required a username and a slug. That looked simple until I learned that the path segment could refer to an organization as well as a person. The application had to respect that rule instead of assuming every article belonged to an individual profile. This is the kind of detail that does not appear in a quick example but changes the shape of a data service.

The featured article on the home page created another mismatch. The API did not expose a featured flag, so the first article was an easy stand in. The problem was that the first article might not have an image, which made the featured block look broken. Switching to a rising articles feed and choosing the first item with an image produced a more stable result. It was not a perfect solution. It was a reasonable adaptation to the available data.

Stores and services

The article screen followed the same pattern as the earlier features: an API service for the request and a component store for the state. That repetition was intentional. A predictable pattern makes a new feature easier to read, even when it creates a little duplication. The duplicates become a useful signal later when the pattern needs to be extracted.

Tag colors presented a smaller but revealing problem. The API returned tags and colors separately, so the interface had to join them into a reusable display. That logic belongs in one place. If every card invents its own color mapping, the visual language becomes inconsistent without anyone deciding that it should.

The first contributor

A contributor started on the listings page. Listings need a masonry layout to make mixed card sizes feel intentional, which meant a new layout problem and a new opportunity to extract a small reusable directive. The contribution was a good test of the project's ability to accept outside work. A project that only the original author can extend is not really a community project.

Notebook note: a public API is a collaborator with opinions. Read its constraints before designing the screen that depends on it.

What remained

The article detail area still needed its main styling, and the comments section had not started. The next week would focus on the article body and the first version of the conversation UI. The application was moving from a collection of pages to a product with a continuous reading experience.