I really want to decouple classes from each other, but I also want to decouple them from any specific DI container, so this is what I came up with. Factory methods passed as arguments.
Is this bad? how would it be better done?

What you're probably looking for is the builder pattern. Possibly with a strategy pattern class for the impl if you truly want to supply all functionality as arguments:

https://stackblitz.com/edit/...

The non-class oriented way to handle this is just function composition.

@SortOfTested
I feel my previous comment was incomplete:

A DI container is going to bind 1 or 2 things to a keyed resource:
- a concretion
- a factory that will produce a concretion

The constructor args determine the Ts that is resolved. If we want our classes to be usable by all DI containers, in addition to manual construction, each constructor arg will be an object* whose lifetime can be managed by the container. Per DI we will:

- Register an abstraction -> concretion relationship
OR
- create a factory and register it with the container, manually resolve deps in the factory code

Usually, concretions will be bound to an abstraction 1:1. When they are not, the builder example will contain the details necessary to wire up possible configs, and be called from the factory.

Sans DI, a builder is useful for making composition easy to read.

* Not all DI support callable interfaces.