Hacker News Reader

Comment by ddek | Hacker News Reader

Most node 'DI' is done using typescript decorators, which have access to the constructor. If you stick to this, you'll always be injecting implementations, which IMO kinda defeats the point of DI. You should be injecting behaviours, not implementations. The workaround is 'DI tokens', but they're a PIA.

My node.js life improved dramatically when I stopped using the OO paradigms, and just wrote functions in native modules.

View on HN

Indeed. NestJS is one such framework that uses DI, it uses type reflection to inject implementations, or you can optionally use a DI token (with `@Inject(token)`).

While I've never been a huge fan of this, it's also usually the least of my problems. On the plus side it makes dependencies between modules explicit which has raised some flags occasionally.

So vramework tries to avoid using OO paradigms except for services. The thing I don't really understand about functions and long lived aspects (like a database connection for example) is that if you don't encapsulate it within a class, you end up with it being on the global scope, which in some way effectively treats the global scope as your class.

How would you for example deal with having a single database pool that doesn't automatically connect on startup (when requiring a class)?

> If you stick to this, you'll always be injecting implementations

You could make abstract classes with error-throwing methods, then extend from those for the implementation.

I think most Node people would think of that as extra boilerplate, though, since DI in Node frameworks usually exists as a side effect of other technical requirements rather than as a design goal in its own right.

In TypeScript that is what interfaces are for.

Reply on news.ycombinator.com