Same here! I’ve been advocating for this approach in every company I’ve worked with, and it’s always been appreciated once the benefits became clear. Spread the word by sharing this series - I might even release a boilerplate showcasing this architecture once the channel gains traction!
Wouldn't this cause more bugs? If I need to manipulate time a lot I will end up just rewriting DateTime as a class Http adapter is different because It adds the ability to hook into requests to display common errors, log them, add caching, etc
Great points! The idea isn’t to rewrite existing tools like date-fns or moment.js, but to abstract their usage when you need consistent handling (e.g., time zones, localization). The adapter centralizes date logic to keep things consistent and avoid rewriting across the app. You can extend it for new use cases without duplicating code. As for HTTP adapters, the same principle applies: it’s about decoupling dependencies (like Axios) to simplify testing and allow flexibility, not adding complexity for its own sake. We’ll dive into that in Part 2. This opinionated approach is overkill for small apps but shines in large-scale projects where maintainability is key.
I saw no frontend devs do that. I hope they also understand the importance of this approach.
Same here! I’ve been advocating for this approach in every company I’ve worked with, and it’s always been appreciated once the benefits became clear. Spread the word by sharing this series - I might even release a boilerplate showcasing this architecture once the channel gains traction!
thanks
Wouldn't this cause more bugs? If I need to manipulate time a lot I will end up just rewriting DateTime as a class
Http adapter is different because It adds the ability to hook into requests to display common errors, log them, add caching, etc
Great points! The idea isn’t to rewrite existing tools like date-fns or moment.js, but to abstract their usage when you need consistent handling (e.g., time zones, localization). The adapter centralizes date logic to keep things consistent and avoid rewriting across the app. You can extend it for new use cases without duplicating code. As for HTTP adapters, the same principle applies: it’s about decoupling dependencies (like Axios) to simplify testing and allow flexibility, not adding complexity for its own sake. We’ll dive into that in Part 2.
This opinionated approach is overkill for small apps but shines in large-scale projects where maintainability is key.
@@neuronfireio Do you maybe have a project example where such pattern is used with date/time libraries?
@edvinasba I'll create a boilerplate to demonstrate real-world examples once the channel grows in subscribers and there's enough demand for it