GitHub repository — https://github.com/ajitsinghkaler/devto-clone
Live demo hosted on Firebase — https://dev-toclone.firebaseapp.com/
In the previous update, I put together a header component that was pure HTML markup. It sat in the layout like this.
.
This week, I started assembling the main content area of the dev.to site. I introduced a dedicated component responsible for handling all the margins and padding applied to the page body. All the inner body sections were added as child routes under this component.
For the body sub-components, I began with a home module. Creating a separate module for the homepage made sense because visitors might land on other routes before reaching the home page. Splitting the homepage into its own module, apart from app.module, opened the door for lazy loading. If the home page is the very first route a user hits, then keeping the home module inside app.module is the way to go.
The home page was broken down into three main areas: the sidebar, the articles feed, and an extra-info block. Looking closely at the dev.to sidebar, I split it further into four components: sidebar-primary, sidebar-social-links, sidebar-tags, and sidebar-advertisement. The primary sidebar handles the default menu options. The social links component manages the social icons that appear when you click "more" on the live site. The tags component covers the tag list, and the advertisement component holds the ad space at the bottom of the sidebar.
With the sidebar's basic HTML structure in place, I shifted attention to the articles feed. That section also got split into three components: a featured article area, a list of articles, and a header.
This is where the dev.to API comes into play. The API has two categories — one requires an API key and the other is open. My plan is to first build out everything possible using the public endpoints. After that, I’ll implement a login flow where the user enters their key, the key gets saved in localStorage, and then we call the authenticated endpoints using that stored token. A natural question is: why not start with the authenticated setup first to avoid rework later? The reason is that I intentionally want to go through a refactoring cycle. Most real-world projects involve a significant amount of rework, and this project is no exception. I think a large share of software development effort goes into refactoring or enhancing existing features, so it's worth practicing on a real codebase.
I used the public articles endpoint (https://dev.to/api/articles) to fetch the article list. I established an articles-api service to handle data fetching and an article-store service that employs Component Store to manage the articles state. For rendering, I’m using Michael Hadly’s rx-angular push pipe because it offers better performance and avoids returning null during initial render. A deeper comparison of async pipe vs. push pipe is a topic for another post.
After these steps, the project reached this visual state.
In the next update, the plan is to add the article section HTML and CSS, plus introduce a tag store and tags API to populate the sidebar tags. Feel free to drop a comment if you'd like more details on any of these pieces.
A shout-out and notes on contributing:
Sunny Vakil reached out about contributing to the project. Thanks for the offer, Sunny — but I only work on this project on Thursdays, so managing additional contributors isn’t something I can take on right now. My suggestion for anyone interested: add a feature request in the issues list. If I approve it, you’re welcome to build the feature yourself and write a follow-up article explaining how you implemented it.