Recipe page challenge using tailwind and angular

What are you most proud of, and what would you do differently next time?

I am most proud of elevating this project from a simple static markup challenge into a dynamic, production-ready web application using Angular (v18+) and the Forkify API. Instead of hardcoding the recipe data, I successfully implemented asynchronous data fetching via Angular’s HttpClient and managed global application states using the modern Angular Signals API.

Specifically, I engineered a highly resilient image-loading fallback logic inside the recipe header. By building a custom circuit breaker using declarative computed() signals and monitoring native DOM (load) and (error) hooks, the component smoothly transitions from an animated Tailwind skeleton loader to the loaded asset—automatically routing to a localized fallback image if the remote API media host times out. This completely eliminates Cumulative Layout Shift (CLS) and protects the user interface from broken layout links.

What I would do differently next time While Angular was a powerful tool for componentizing the layout, it was arguably a bit over-engineered for a single-page challenge. Next time, I want to expand this layout into a multi-page recipe book by taking full advantage of the active routing architecture I put in place.

What challenges did you encounter, and how did you overcome them?

I ran into a challenging infinite rendering loop when trying to pre-hydrate images via a hidden background <img> tag alongside fallback routing. While I successfully resolved it by refactoring to pure computed signals, next time I will establish a strict Unit and Integration Testing suite (using Jasmine/Karma or Playwright) right from the start. Writing tests early would help me catch DOM lifecycle race conditions and asynchronous asset edge cases before writing the template code.