JavaScript – Module Requiring vs Dependency Injection

design-patternsjavascript

These days a question popped out in my mind:

Does the way we Javascript go against almost everything that is considered a good practice in traditional Software Development?

I have a series of question/observations related to this statement, but in order to respect StackExchange's format, it will be better if I split them into different questions.

Module requiring

Standard Javascript code nowadays looks like:

const someModule = require('./someModule')

module.exports = function doSomethingWithRequest() {
  // do stuff
  someModule.someFunc()
  // do other stuff
}

Advantages

Encapsulation: the module works standalone and know everything it need to perform its functions.
As a colorary, it's easier to clients to use the module.

Disadvantages

Poor testability: this is standard when not using DI, but in dynamic languages, such as Javscript it can be circumvented* by modules like mockery or rewire.
It certainly violates the DIP — not to be confused with Dependency Injection. — since I can only import concrete modules.
It probably violates the OCP — for example, imagine that I have a log module that writes to the file system (through fs module). If I want to extend this log module to send it to the network, it would be very hard.

_{* This might work with CommonJS or even AMD modules since they are implemented mostly in the user-land. However, I'm not sure how this could be possible with ES6 import syntax.}

Dependency Injection

Using dependency injection, it would be more like:

module.exports = function doSomethingWithRequest(someModule) {
  // do stuff
  someModule.someFunc()
  // do other stuff
}

Advantages

Increased testability: now it's easier to stub/mock someModule, even using the ES6 syntax.
It's possible to honor the DIP: not necessarily though, as the client module can still be programmed to the implementation and not an interface.

Disadvantages

Broken encapsulation: the main question remaining is:

Ok, then who will create/require the dependencies?
Doing that in every client of the module seems very WET.
This would probably require me to use a DI Container in order to be feasible in a real project.

So, the real question here is:

Why Javascript developers tend to lean towards the first approach?

Is this just "the Javascript way"?

I myself write code like this most of the time. I've had my fair share of test setup using mocking libraries, but it always felt kind of wrong doing so.

Am I missing something?

Best Answer

I am mainly a PHP programmer, but have been in contact with 4 JavaScript teams for the past year or so.

As an object-oriented programmer the dependency injection principle would seem the best way, however I have been told otherwise by few JS developers. JS is a whole different world.

Because JavaScript allows you to monkey patch anything and everything using very simple techniques, JavaScript developers learned to adapt a different technology on how to build larger scale JavaScript applications. Most of these are build as sets of self-contained modules, which expose funcionality through public exports, hiding internals of the module as not to allow others to rewrite the functions on which you rely.

The usual approach usually is to even go as far as to not expose a constructor what so ever but rather expose constructing of an object using a factory wrapper - for the exact same reason: if you give someone access to an object they can instantiate directly they are allowed to change anything.

By taking advantage of the modular design you deny others to fiddle with your functions you expect to work, but you still have the ability to test your modules - through the public API of the required file, the API you created.

Related Solutions

Dependency Injection – How to Use DI and DI Containers

As there is no right or wrong in this question, I could give an example about how I like to use Dependency Injection in PHP.

I'm using the Dependency Injection Component from Symfony with the LosoDiAnnotationsBundle and extracted everything from the Bundle to use it as standalone as the Dependency Injection Component. I'm not using the rest of the Symfony Framework.

There are two functions in my system which use the Dependency Injection Container. The main function and the dispatcher. The main function (application entry point) retrieves the configured Dispatcher like this:

$dispatcher = $service_container->get('Dispatcher');
$response = $dispatcher->route( $request );

The service called "Dispatcher" is either defined in the global dependency config or annotated in the class itself like this:

 /*
 * @Service
 */
 class Dispatcher {
    /**
     * @Inject({"@service_container"})
     */
    public function __construct($serviceContainer) {
        $this->serviceContainer  = $serviceContainer;
    }
 }

The Dispatcher needs this service locator because thats how my routing works. If you use some extra mapping between routes and called methods, you could avoid this.

To inject something into other services I use the @inject annotation:

/** @Inject({"@SomeLogic", "@SomeGateway"}) */
public function setDependencies(SomeLogic $someLogic, SomeGateway $someGateway) {
    $this->someLogic = $someLogic;
    $this->someGateway = $someGateway;
}

I like this approach because the configuration of a Service Class is done in the class itself and not in a separate file. Refactoring doesn't involve messing around with lengthy XML or YAML files.

To not harm the performance I run a script everytime I change some annotations and at build time (or in general on every vagrant up). It uses Symfony's ContainerBuilder and PHP Dumper to generate a PHP Lookup file which extends the Base ServiceContainer Class.

The lookup for the example dispatcher would look like this:

protected function getDispatcherService()
{
    return $this->services['dispatcher'] = new \Some\Dispatcher($this);
}

This looks like a lot of work upfront, but it clearly separates concerns later on, especially in bigger projects. Classes do what they are supposed to do and need little to no non-domain-logic code at all.

And I try to keep factories to an absolutely minimum. The DI Container itself is one big factory and repository but it is not manually maintained.

EDIT:

My Routing Function looks like this, request_uri is something like Controller/action/...

    $path = explode( self::ACTION_SEPARATOR, $request_uri );

    if( empty( $path[1] ))
        throw new RoutingException( 'Invalid Action' );

    $method = ucfirst( $path[1] );
    $className = $path[0].'Controller';
    $qualifiedClassName = 'Some\\Namespace\\'.$className;

    if( !class_exists( $qualifiedClassName ))
        throw new RoutingException(sprintf('Invalid controller "%s" for route "%s"', $qualifiedClassName, $route));
    if( !is_callable( array( $qualifiedClassName, $method ) ))
        throw new RoutingException(sprintf('Invalid Action "%s"', $method));


    $controller = $this->serviceContainer->get( $className );
    call_user_func( array( $controller, $method ), $message );

Single Page Web Applications – Requiring JavaScript

I'd say no. It could've been bad 5-10 years ago to create a web application that requires JavaScript, but technology is advancing, and as such, web applications are becoming more dynamic, and require proper processing technology. This is where JavaScript comes in.

Single page web applications are likely to be even more heavily reliant on JavaScript, as they tend to make strong use of AJAX calls to show data.

At the end of the day, you could theoretically make a single page application in server-side code such as PHP, but the quality of the website will be severely lacking in comparison to one that takes full advantage of the technology available today.

Module requiring

Advantages

Disadvantages

Dependency Injection

Advantages

Disadvantages

Best Answer

Related Solutions

Dependency Injection – How to Use DI and DI Containers

Single Page Web Applications – Requiring JavaScript

Related Topic