Echo JS 0.11.0

<~>

andrei.gabreanu 3063 days ago. link 1 point ▲ ▼
@tracker1 - For me it makes a lot of sense for a couple of reasons:

1) The module system in JS is OK as long as you are targeting client side code. When we're talking about server side (thinking universal apps) as well it suddenly becomes an issue where you need a *certain* instance and not sharing it thus sharing the state. What you end up with is a need to manually somehow get your dependencies while you cannot (at least not by default) just require your dependency. 
Moreover, I find it that using a DI system makes testing much cleaner vs mocking the require and thus hiding the actual dependencies a certain module needs. Not saying it is a bad way to do it but it just makes sense for me like this, especially coming from a PHP background. I saw that the industry also starts to see this. Check redux (if you are familiar with it) with the latest release for the redux-thunk, where they allow you to pass a "DI" object which contains whatever you want.

1) We at Middleout are using Typescript exclusively for everything so we have types for almost everything, thus types injection via constructor (or method) seems much cleaner overall.

2) We are working quite a bit in an OOP fashion so classic dependency injection makes more sense than the current module system IMHO. 

I do agree that DI systems usually make it harder to track stuff down (In some worst case scenarios I had to add logs to see what is being constructed from where) but I find the gain of having explicit constructor dependencies *and* auto creation of objects an overall positive gain. 

If you are developing a small app then of course, DI is usually an overkill, especially if you are not actually hitting any of the universal code issues (thus making the modules system perfectly fine in theory).

Thanks for the comment!
tracker1 3063 days ago. link 1 point ▲ ▼
Still not a fan of DI in JS, especially with it's easy module system... it's easy enough to export a single instance in a module, and if you only need one instance, then you can create a wrapper that everything else imports that give you the instantiated instance explicitly.

DI systems make it hard to track down where something came from, makes for disconnected code that's often harder to debug and test against, and in general is usually a complexity that is best avoided.

DI makes far more sense in a statically typed environment that requires certain types of inheritance for testing.  Although it *may* provide value if you're writing your tests in TypeScript, I would emphatically *not* use this for JS.