Build journal: tags, listings, and observable states

This week added two more sources of content to the home experience. Tags became a real feed instead of a visual list, and listings arrived with a layout of their own. Both features followed the same basic pattern: an API service for the request, a store for the result, and a template that renders the current state.

The tag path

The tags section now uses the public API to retrieve articles for a selected tag. The interface can show the tag name and a short set of recent items without rebuilding the article card. The card itself became a shared piece because the feed, the listing page, and the tag view all needed a consistent summary. Sharing a component is more useful when the component's job is narrow.

A reusable tag component also displays top articles from a tag over a recent window. The component takes the tag as input and owns the request lifecycle. That makes it easy to place in more than one context without copying the fetching logic. The pattern is not complicated, but it is the sort of thing that saves a project from repeating itself in five slightly different ways.

Observable states without the async pipe

RxAngular's template utilities were the most interesting part of the week. The template could distinguish between loading, success, error, and complete states without stacking async pipes and structural directives. That matters for a real interface. A loading spinner, an empty message, and a failed request are not the same thing, and a template that treats them as one state will eventually feel vague.

The tradeoff is another concept to learn. A framework primitive that adds expressive states also adds a vocabulary the next developer has to understand. The right response is not to avoid it, but to keep the usage consistent. If one feature uses four states and another uses none, the codebase becomes harder to reason about.

Duplication worth watching

The tag store and the article store now share a lot of shape. The listings template and the tag template also look related. That is not an emergency, but it is a signal. The next refactor should ask whether one store can serve both cases without becoming a general purpose data bucket. A shared abstraction is useful when it makes the product easier to describe. It is harmful when it hides two different behaviors behind one name.

Notebook note: loading, empty, error, and success are four different stories. A template that can tell them apart is usually worth the extra concept.

The next screen

The next week would move to the article details page. That screen would bring the article body, the conversation, and the read next area together. It would also be the first place where the application needed to handle content it did not create, which is usually where layout assumptions start to break.