Best practice for managing dependencies and mocking them about nodebestpractices HOT 4 CLOSED

@syzer I have thoughts whether DI should remain in the handly developer toolbox in 2017. I saw 3-4 huge NG applications in the last 2 years and none really needed DI.

can you exemplify a typical scenario in backend app that is well modularized into services where one need a *framework to make the decision which provider to instantiate?

Disclaimer: I used a lot DI framework in the past

from nodebestpractices.

Cool topic. Managing in terms of testing only? management can encompass the entire NPM domain, we should narrow this scope

from nodebestpractices.

@i0natan its not only about testing.

Most frameworks have already DI injection micro framework in them.
So that would be very framework dependent

Personally I like how (JSR330) is doing

@Inject private Logger logger;

Angular 2 does very similar annotation based approach.

Other good Idea is using registry with all dependencies lazy resolutions,
via (anonymous functions/arrows) or getters get() { .. }

All above allow hot code loading/push on servers and frontends.
(And easy mocking for test.)

from nodebestpractices.

Hi!

I think DI is very important for testing, code purity (as in controllable side-effects) and functions (units) that define their dependencies up-front.
I found it is hard to educate regarding this topic, as it mostly produces only more code before it really gets useful in mid to large scale applications. (large scale speaking of ~10000 LoC). Even in smaller applications it can be of great help to make even side-effectful functions to work in unit tests.

I think we can still put it as a best practice with maybe a few concrete hints or libs.
Whereas I myself has experienced that DI can be done properly and easily without additional libraries.

Examples:
Simple:

const random = (Math, max) => Math.random() * max

Complex:

complex module requiring different other modules and libs:

const startServer = dependencies => {
    const app = dependencies.express()
    app.listen(dependencies.env.PORT, () => {
        dependencies.log(`server started on ${dependencies.env.PORT}`)
    })
    return app
}

const express = require('express')
startServer({ express, log: console.log, env: process.env })

Good alternative names for dependencies is ctx, context or options.
Mixing options and dependencies is okay for me IMHO. One can also separate these if needed.

from nodebestpractices.