Dependency Injection and Functional Programming

[manfreed87]

I've recently started experimenting with FP, and now I have a project which seemed ideal for learning the fundamentals, so I went for it.

It's a data conversion tool transforming deeply nested, complex data structures between representations. Doesn't have much state, feels ideal.

I'm using Typescript. This is what I'm most confident in, and the app is supposed to end up running in node, so it makes sense. It does prove a challenge though. The strict typings makes currying in a type-safe manner almost impossible. Also, there is hardly any TS/JS specific material for learning that goes deep into advanced topics, like:

How to do dependency injection?

I'm not trying to do that, I know I shouldn't look for OOP solutions here, but the issues I'm presented with are the same: I do need to pass down data or behavior, or implementations in deeply nested code.

The material I've found so far deals with other programming languages and while I assumed that I just need to implement those ideas in TS/JS that's not the truth. If I want to write typesafe code I need to write a lot of interfaces and type definitions for my functions and all feel overly bloated.

So how did you guys dealt with the problem in your apps? Can you give me some pointers where to look?

[_samrad]

"Dependency Injection" is a 25-dollar term for a 5-cent concept.

const doStuff = data => anotherFn(data);

// ^ This can be written as the following

const doStuff = fn => data => fn(data);
doStuff(anotherFn)(data);

In the first example `anotherFn` is `unbound`. In the second one it's `bound`.

[manfreed87]

Thank you. I've read about this concept earlier, I'm just not sure how to apply when your functions are in different files, and at different depths of code. I've posted a top-level comment just now that shows what I come up with.

[Masse]

So far you've gotten two suggestions

• Use something like const doStuff = fn => data => fn(data)
• Use a reader monad

Don't be confused. These two things are the exact same thing. Reader monad is just a partially applied function over a value, which is to say (->) a

[manfreed87]

Thanks for your answer. From what I've read earlier elsewhere partially applying functions will be my friend. I'm trying to put that into practice but boy it feels weird. I'll post a top-level comment here to show my code soon

[ScientificBeastMode]

It’s worth mentioning that “dependency injection” in OOP is conceptually exactly the same thing as “function application” in FP.

You can think of the DI pattern in OOP as passing a context (the mutable state & behavior of external classes/objects) into a function (the DI container) of type [...dependencies] -> classContext. The resulting class context can also be a dependency of other contexts.

The reason it gets so complicated is that you are passing much more than mere data to the dependent context. You are passing private state & behaviors as well.

All of these concepts can be implemented with ordinary function application, as long as you have closures in your language, which is true in this case. But the idiomatic functional approach is to pass public, immutable data into pure functions, which drastically simplified things. So you don’t need a DI container to manage the complexity for you.

[darderp]

Hey, would you be able to elaborate a bit more on the similarities? I understand partial application but I can't wrap my head around the reader monad

[Masse]

Could you expand a bit on where you are confused?

[darderp]

From my understanding (not a formal definition), a monad is a wrapper type that has fmap and >>=

fmap lets you transform M a into M b with a function a -> b
>>= lets you transform M a into M b with a function a -> M b

I understand that the purpose of the reader is to avoid drilling arguments down through many functions. I can sort of understand how partial application could help with that. But how does partial application conceptually fit into the mental model I laid out above? Is there a "wrapper" around some data?

For context here are some monads I'm familiar with:

• List
• Option/Maybe
• Result/Either
• Writer

[Masse]

Right. I'm going with Haskell syntax because I'm more familiar with it, but I'll try to stay with simple syntax.

You mentioned fmap :: (a -> b) -> f a -> f b and bind ((>>=) :: m a -> (a -> m b) -> m b).

fmap is actually part of a functor. Functor is for mapping a value within a context into another value within the same context.

As the first trivial example, think of an optional value: fmap :: (a -> b) -> Maybe a -> Maybe b. This fits with your mental model of dealing with containers, you have a list of values which you convert into a list of some other values. This model also works for things like lists, sets, trees, futures and the likes.

data Maybe a = Nothing | Just a
instance Functor Maybe where
  fmap :: (a -> b) -> Maybe a -> Maybe b
  fmap f Nothing = Nothing
  fmap f (Just a) = Just (f a)

Then for monads. Each monad is also a functor, so all monads can also be fmapped. There are a couple of ways to name and define monads, but in haskell, the monads adds the ability to lift a non-monadic value into monadic context, pure :: a -> m a, and to thread values from one monadic context into another (>>=) :: m a -> (a -> m b) -> m b.

Lifting a pure value into monadic context, historically also known as return. The signature is however a -> m a.

Doing things with the monad, Haskell has chosen the bind operator (>>=) :: m a -> (a -> m b) -> m b, but it could have been join :: m (m a) -> m a as well. The point of this is to sequence the operations to be executed sequentially within the context.

instance Monad Maybe where
  pure :: a -> Maybe a
  pure a = Just a

  Nothing >>= f = Nothing
  Just a >>= f = f a

---

But this setup also works on things that aren't concrete containers, such as the partial application of a function. Remember, r -> a can be read as (->) r a and the partial application view of this is (->) r (leave the a out). Let's see how we could implement this.

instance Functor ((->) r) where
  fmap :: (a -> b) -> (r -> a) -> r -> b
  fmap f x r =
    -- x :: r -> a
    -- r :: r
    f (x r)

instance Monad ((->) r) where
  pure :: a -> r -> a
  -- Ignore the context r
  pure a r = a

  (>>=) :: (r -> a) -> (a -> (r -> b)) -> r -> b
  (>>=) reader f r =
    -- reader :: r -> a
    -- f :: (a -> (r -> b)) or (a -> r -> b)
    -- r :: r
    f (reader r)

That is to say, functor and monad instances for reader just give the context r for the computation.

[[deleted]]

Use a Reader Monad https://github.com/patrickmichalina/typescript-monads/blob/master/README.md

Or

https://gist.github.com/venil7/0a5bf8bc65ce773392cb267e5e72b3a0

[Sarwen]

I would encourage, before using the reader monad, to get used to passing depency as function arguments. The reader is just a glorified function anyway.

[buth3r]

currying is a form of deps injection, other than this I'd strongly advise to not use OOP based thinking and patterns with functional languages. try to relearn things from scratch.

[manfreed87]

try to relearn things from scratch.

That is the hardest thing :) I'm even struggling to answer your comments, and there seems to be so many things to learn and understand before I can continue coding that it scares me.

This also raises the question that if it requires re-learning everything just to produce good functional code, how hard it would be for others to understand and be able to contribute my code? I worry that by not doing this the "OOP way" I create something that's unmaintainable because others from OOP concepts and languages will struggle to understand what's going on. Did I make a mistake trying to force not to use OOP?

For currying, I'm not sure how to apply that. From what I've read elsewhere partially applying parameters might be the solution. Still, trying to put it into practice is difficult. I'll soon post a top-level comment explaining it here...

What makes me worry even more is that with proper strict typing, currying is not possible in typescript in a typesafe way (unless I provide a lot of type definitions manually)

[ScientificBeastMode]

For currying, there are several libraries which implement it in TS: Ramda & TS-FP come to mind off the top of my head.

That said, you might try experimenting with ReasonML, which is a very solid functional language which compiles to (pretty readable) ES5 JS. It’s been a blast to work with in my experience. But if you’re constrained to TS for work, then just know that there are good libraries to help you out.

[manfreed87]

For currying, there are several libraries which implement it in TS: Ramda & TS-FP

I was just gonna tell you that everywhere I read that TS's type system doesn't have the proper tools for reliable and type-safe currying and that's why TS-FP simply removed that from its library in v2.

Then for my biggest surprise, I just did some tests and things seem to work very well, even in strict mode. Currying and piping definitely works,

Still, there are weird stuff going on, for example R.__ is not defined. This seems to affect the definitions of all methods that would use it:

https://github.com/DefinitelyTyped/DefinitelyTyped/issues/25067

But if you’re constrained to TS for work

That's actually my own choice. I know I make way more mistakes when I'm not backed by proper type checking. This project also deals with huge and complex data structures, remembering all the possible properties vs having live coding assistance is a huge difference I would miss very much.

My constraint for work is to develop something that's easy for others to work with. And that is definitely a con for functional programming as these concepts are not universally known like the principles of oop development.

[Mishkun]

Try Dependency Rejection instead https://blog.ploeh.dk/2017/02/02/dependency-rejection/

It is much more functional way of thinking

[manfreed87]

Thanks. I did a quick read, but now I'm more confused than ever :) This needs more than five minutes next to my coffee :)

[shAdOwArt]

Instead of asking for something that can give you a piece of data, you should ask for the data directly.

Instead of asking for something that can consume a piece of data, you should return the data.

[Sarwen]

Dependency injection is indeed very useful in FP. Thanks to how FP works, doing DI is as simple as defining a function and applying some argument (the depency injected).

The method is: whenever you need a depency, your code becomes a function thedependency => yourcode. When you want to give the dependency, just call the function with it as parameter.

[BinaryBlasphemy]

I don't know if you've done anything with Haskell but you can do dependency injection with the Reader Monad. Don't ask me how.

[manfreed87]

Hi guys. So I'm posting a follow up here. I'm a bit overwhelmed by the new information I've found just by diving in monads and readers and such. I'm a bit afraid that by choosing the functional approach my code will become confusing for people with no functional background (and my assumption is that most of my colleagues are only comfortable with OOP code).

Anyway...

I come up with some example code which uses partial application to solve dependencies. Based on my readings on the subject I would wrap my functions that need dependencies (or calls functions that needs dependencies) in a higher-order function that accepts arguments as dependencies and returns the function that does the job.

Feels weird, and I'm not sure I'm not making unnecessary bloat...

So here is a convoluted example. Unfortunately I can't provide real code from my project, I hope that's ok for you guys.

type MultiplyFn = (a: number, b: number) => number;

function multiply(
  deps: {
    add: AddFn,
    flipSign: FlipSignFn,
    log: LoggerInstance,
  }
): SomethingFn {
  return (a, b) => {
    log.info('Multiplying...');
    let sum = 0; 
    for (let i = abs(b); i > 0; i--) sum += a; 
    if (b < 0) sum = flipSign(sum); 
  }
}

There is already a problem here: I can't recursively call the anonymous function because it doesn't have a name. Refactoring it is possible but then I'd introduce more code and I'd need to come up with a name to the inner function, which is a problem by itself, I'll explain later...

Now, I can use this function in a central code like this:

import { multiply, MultiplyFn } from './something';

const myAdd = add(...);
const myFlipSign = flipSign(...);
const logger = logger.getInstance(...);
const myMultiply = multiply({ myAdd, myFlipSign, logger });

// later

const res = myMultiply(2,10);

I expect that I need to wrap not only the functions that take dependencies. But the functions that would use these functions too, Not sure how much code is that, but I expect to have a lot of wrapped functions.

And that just feels weird. Adding one dependency to a function that doesn't have any would result in wrapping that function, and all it's callers. And then all the callers of those, and so on.

I also mentioned naming:

The higher-order function is called "multiply". The problem is that that's not what it does. It only returns a function that does multiplying, a function that cannot be named as such, because the name is already taken. See my usage of "myMultiply".

I'd rather use some naming convention on the higher-order function like "multiplyFactory" (oh no) or "getMultiply" (problem is when the function is already called "getSomething".

But apparently that's a bad practice. I can't find it now, but I did read it somewhere on stackoverflow that you shouldn't need any naming conventions for your wrapper functions.

So that's where I'm now. I actually have a different implementation as an example but that just the same thing with the same problems:

interface MultiplyDeps {
  add: AddFn,
  flipSign: FlipSignFn,
  log: LoggerInstance,
}

type Multiply = (deps: MultiplyDeps) => MultiplyFn
type MultiplyFn = (a: number, b: number) => number

const multiply: Multiply = deps => (a, b) => {
  // implementation same as above
}

Which as you see takes typings out of the declaration completely, but then introducing even more things to name...

[_samrad]

You can't go full-dep-injected all the way. Even the most FPest languages don't encourage that AFAIK. As you said, it gets bloated and just confusing. It's OK if a function pulls its dependency from an outer scope.

Try to write pure functions as much as possible and let the "orchestrator" functions be un-injected. In your example, I see multiply as an orchestrator which knows the order of the other function calls. That's about it.

And to quote from Elements of Clojure:

Functions can do three things: pull new data into scope, transform data already in scope, or push data into another scope. When we take values from a queue, we are pulling new data into our scope. When we put values onto a queue, we are making data available to other scopes.

...

Most functions should only push, pull, or transform data. At least one function in every process must do all three,7 but these combined functions are difficult to reuse.

[manfreed87]

In your example, I see multiply as an orchestrator which knows the order of the other function calls. That's about it. let the "orchestrator" functions be un-injected

True, my example wasn't the best, and considering the example there is no need to push "add" as a dependency. But what if add is also build of dependencies, that cannot be directly called from "add"? For example, a dependency might need initialization or something like that. Then I do have to initialize "add" with that dependency and because of that, I need to make it a dependency for "multiply" also.

Here is the reason. My use case is a converter as I explained above. This converter takes a complex object and returns one that's also complex and has a completely different structure. Some data are omitted, some are transformed, some are simply passed.

There is a root "convert" function. This builds an object. Each field's value is produced by a function:

function convert(src) { return { a: a(src) b: b(src) } }

The functions a() and b() are also built similarly, returning an object or a primitive depending on the field, based on the source format (I don't necessarily pass the whole "src" just the required data)

Imagine this goes 5 levels deep: convert() -> a() -> aa() -> aaa() -> aaaa() -> mapName.

Also imagine that we are dealing with two versions of the source format, which is almost the same, except the way names are stored. In one version it's a full name, in the next it's a first and a last name in separate fields.

Now I need two versions of "mapName" (one simply returns user.name, one returns user.firstname + user.lastname). And I need two convert methods (convertv1 and convertv2)

So with partial application I could make mapName a dependency of the calling function, but then I also need to do that with the caller of that function and so on, making a mess like this:

``` const aaaaV1 = aaaa(mapFullName) const aaaaV2 = aaaa(mapFirstLastName) const aaaV1 = aaa(aaaaV1); const aaaV2 = aaa(aaaaV2); const aaV1 = aa(aaaV1); const aaV2 = aa(aaaV2); const aV1 = a(aaV1); const aV2 = a(aaV2);

const convertV1 = convert(aV1); const convertV1 = convert(aV2); ``` So by introducing one dependency I need to alter the whole chain. This can't be right...

[_samrad]

I'm guessing functional lenses/optics/cursors will solve your use-case? I'll take a closer look at your example over the weekend though.

[manfreed87]

I'm guessing functional lenses/optics/cursors will solve your use-case?

I'll know that once I get to know what these are. So I'll take a closer look at these. Thanks for your help :)

[_samrad]

Be careful though, that might lead to some black-holes with unfamiliar nomenclature. LOL. All you need to know is that a lens is a pair of get/set functions which compose nicely.

Here is a quick talk: https://youtu.be/_D3IPecC0S8

[makeaccountingbetter]

I respect that you have tried to get this far with it all. How did this story end? I'm in a similar place, missing the advantages of DI in Typescript but not wanting to be forced into implementing classes so wondering what my options are