DI makes testing nice. People approximate it with hacks, but you need DI for truly good unit tests.
Really depends on the whole structure. If it is mainly FP, dependency rejection usually is actually the easiest to test with
I dunno how you can combine dependency injection (as I imagined it in the original comment) with FP in the first place.
Without classes what would you be injecting? Other functions? That’s still something that happens all the time in FP.
I was thinking sideeffectful functions. Such as DB accesses.
> dependency rejection
That’s secretly the most powerful design strategy.
Personally I find DI to make it harder to reason about in a sizeable portion of cases (20ish%) without actually providing a benefit.
So that makes me prefer going for rejection (Passing the result of the dependency instead of the dependency itself) or just keeping it there.
Altough, those approaches depend heavily on the rest of the codebase. (FP makes rejection relatively easy for example)