Do we really provide "DI"?

[BANOnotIT]

Discussed in #570

^{Originally posted by BANOnotIT May 15, 2023}
There's a design pattern called Inversion of Control. In general, it states that it's not you who call some functionality but something, namely framework or library, calls your code when something specific needs to be done. You delegate some functionality to some other code and handle its result later. The simplest example of IoC is Callback pattern that is widely used in Node.js and Listeners that are used by Web platform in general.

Dependency injection is a specific form of IoC that is used to compose complex things using simple ones. DI is used to delegate composition to someone. Many DI libraries employ interface/implementation segregation to replace one implementation with another without breaking the interface. Also, there are many features in contemporary DI libraries such as conditional resolution, scopes, and lifetime control.

Reatom uses IoC in these situations:

• hooks are the iconic IoC pattern employed by many frameworks and libraries
• atoms delegate storing state to context
• computed atoms dependency tracking is delegated to context also

But reatom doesn't provide any functionality to compose atoms automatically. All atoms are explicitly composed by a developer using ctx.spy(specificAtom) and ctx.get(specificAtom).

Note: atom fabrics, such as reatomAsync, are fabrics which are producing pattern.

I propose replacing "Implicit DI for simple SSR and testing" with something else. SSR often involves IoC usage to unify the state among servers and browsers. Testing, mainly unit testing, does heavily encourage IoC to only test one unit at a time but still doesn't require DI to work.