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 location
or 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 @Autowired
/@Inject
decorator).
I'm also interested in any other insights about this architectural concept. For instance, do you think it is a good idea to use classes, or simple JavaScript-style objects would suffice or even fit better? Are responsibilities well divided with it, or would you structure things differently?
location
a component.