Build journal / week 8
Build journal: comments, grid fixes, and a deploy pipeline
A week of article layout work, a new comments branch, a contributor's video page, and the first automated deployment.
The application now has a more complete article detail view. The middle column received the styling it had been missing, and the first version of the comments section moved onto its own branch. Splitting the work this way kept the main experience stable while a riskier feature took shape.
When the layout is the bug
A frustrating part of the week was a layout problem that looked like a code block problem. The article body was injected into a grid, and the grid behaved as if its content had no reliable width. Elements that should have overflowed inside their own containers were pushing the whole composition. The fix came from inspecting the grid itself rather than continuing to adjust the inner blocks. It was a useful reminder that the nearest visible symptom is not always the source.
Article content also needed a safer default for images and code. Long source lines can force a column wider than the page, especially when the source is not under the layout's control. A combination of maximum widths, flexible tracks, and overflow rules made the page more resilient without flattening the design.
A contributor expands the shape
Another contributor built the video detail page and added infinite scrolling. That work was valuable for more than the feature itself. It tested whether the application could support a second content type with its own reading pattern. The page was not just an article with a different label. It needed a different rhythm, and the contributor gave it one.
Reaction state also moved from a static display to a store backed by the available data. The public API did not provide a complete write path for reactions, so the interface had to be honest about what it could and could not do. A read only presentation is less exciting than a fully interactive one, but it is better than a button that pretends to work.
The first deployment action
The repository gained a GitHub Actions workflow that built the application and deployed it to Firebase Hosting on the main branch. CI and CD had been familiar on GitLab, but the vocabulary and structure of GitHub Actions were different enough to require a fresh mental model. The first pipeline was basic, and that was the right scope. A deployment that runs reliably is more valuable than a complicated workflow that nobody trusts.
Notebook note: when a layout fights you, inspect the track before rewriting the child. When a platform feels unfamiliar, build the smallest working pipeline first.
One project, several branches
At this point the work lived in three places: the main experience, the comments experiment, and the video page. Keeping those branches visible made the state of the product easy to discuss. It also raised the question of whether the project should move to Nx. That decision would shape the next several weeks.
Reference shelf
Selected external references for going deeper.