I'm spending some time lately reading and thinking about alternative ways to build web applications. One of the approaches I'm experimenting with is heavily based on OO, using TypeScript. The general idea is to divide the application into ever-smaller components, similar to the way Angular (and so many others) does it.
One important aspect of it is that components define their APIs (such as callbacks to be executed after some event) as part of their constructor. This is a nice way to establish communication between components.
Another facet worth highlighting is that each component is responsible for the bit of HTML it is associated with, which is created programatically (the idea behind this particularity is to provide type-safer HTML) by the component itself.
As a proof of concept, I created a small to-do application, available at https://jsbin.com/sopener/edit?js,output.
My question is: now that components' constructors have already a good purpose, what options do I have to manage dependencies of those components, such as services responsible for server communication, browser-specific objects such as
document, etc.? Hard-coding those dependencies would make testing very difficult, and expecting them as part of the constructor, mixed with the rest, would make things unclear, and it would make difficult to implement some kind of Spring-like dependency injection facility (e.g. an