# General Concepts ## Introduction Dependency injection is a common technique in software development. If you are not familiar with it, and you are curious about technical details, you might find more information on this wiki page: {% embed url="" %} With dependency injection, you get to delegate the responsibility of creating the objects that encapsulate the logic of your system, basically ConanJs will create the objects for you, the objects created this way are called **beans** {% hint style="success" %} Dependency Injection is a bit like testing, if you are new to it and have never tried it, it will look intimidatory and unnecessary. But similar to testing, once that you try it and understand it, there is no turning back. If this is your first contact with dependency injection, we would suggest to head first to [Creating the context](https://docs.conanjs.io/dependency-injection/creating-the-context) to get some hands on perspective. {% endhint %} In summary: * You will describe what objects you want to create through **bean definitions** * You will pass a key value pairs of **bean names** to **bean definitions** to the **ContextFactory** * The context factory will **resolve by name** the objects to be created according to your **bean definitions** and create the **beans** * Finally the **beans** will be accessible through the **context**. Let's have a look at each of these terms ## The Beans A bean is a plain JS object that is resolved on the back of the bean definitions that you provide to the [**DiContextFactory.createContext**](https://docs.conanjs.io/api/dependency-injection/dicontextfactory). In other words, **the bean is the final object that ConanJs creates for you and that it will be available from the context.** {% hint style="success" %} The name bean is taken from the [Java World](https://www.baeldung.com/spring-bean). Some people will argue that we named it like this so we could say that this is the first framework ever with [TACOS](https://docs.conanjs.io/data/general-concepts#attributes-tacos) and BEANS... they might be right. {% endhint %} ![A rare capture of ConanJs providing Beans through the context](https://3967196510-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M3BBQqsBUGjmzTvukhE%2F-MCQoqOJ03iosqAEl-AM%2F-MCQpEudbPXNQjDkuw6X%2Fbeans.gif?alt=media\&token=e3a69c2d-26d2-4212-93e0-e6c1db5ad46e) ## The context The Context is a plain object that contains the beans. The context is created through the [**DiContextFactory.createContext**](https://docs.conanjs.io/api/dependency-injection/dicontextfactory)**,** this method receives the key value pairs of **bean names** to **bean definitions** After the context is created, the beans can be accessed directly by referring to them by their **bean name**. Ultimately, on your code you would be importing the context and accessing the beans from there. This decoupling is the essence of the dependency injection, on your code you don't know where these objects are coming from, you just declare that you need them through the context. {% hint style="success" %} Since the context wraps the beans, we were tempted to call it, **the tortilla**, but as you can tell by our naming policy and docs, [we are serious people.](https://docs.conanjs.io/about-us) {% endhint %} ### **Bean definitions** There are two types of bean definitions that can be passed to the contextFactory to be resolved into beans: * **Hints**. (**A function or class).** ConanJs will understand that your are hinting that an object using the class or the function needs to be created, and it will create it for you. * **Values. (An object).** ConanJs will take the provided value as the bean value. This is handy if you want to put a straight value on the context, or because you want this value to be resolved as the correct dependency for a hint. When passing hints to the [**DiContextFactory.createContext**](https://docs.conanjs.io/api/dependency-injection/dicontextfactory)**,** ConanJs will look for any **unresolved dependencies** for the hint, and will resolve them recursively by name (this is explained in details on the section below). ## Resolving Dependencies Resolving each bean definition into a bean is the process called Resolving Dependencies. Resolving **values** is straight forward, the value for the bean is exactly the same value as provided to the DiContextFactory. **Resolving hints** is more complex, when resolving hints there are three scenarios based on the underlying function or constructor parameters. * **No parameters**: The function/constructor is invoked, the return value is the bean. * **With parameters:** If the hint has parameters, the **resolution by name** starts where each parameter is resolved and when all of them are resolved, the function/constructor is invoked with the parameters, the return value is the bean. ### Resolution by name Resolution by name is the process by which a hint needs its parameters resolved. ConanJs will obtain the name of the parameter, and resolve it agains the context. This is where the recursive nature comes into play, basically there are two scenarios when a parameter needs to be resolved * if there is a **value** with the same name provided in the context, is resolved to that value * If there is a **hint** with the same name provided in the context**,** it recursively resolve it. {% hint style="success" %} If you are familiar with DI you might be aware of the different flavours of resolutions, for instance type resolution... ConanJs being JS based, and JS not having types means that we can only support name resolution. {% endhint %} ## Aux bean definitions Lastly, is important to understand that you can optionally pass a second set of key value pairs of bean definitions to [DiContextFactory.create](https://docs.conanjs.io/api/dependency-injection/dicontextfactory), these are called **Aux beans definitions.** If you do this, ConanJs will combine both bean definitions for the purpose of resolving any bean, just as if you have passed them together, the difference is that **the context will not expose the resolved beans for the Aux beans definition.** This is handy, as many times you will have bean definitions passed to only satisfy internal implementation details, and it doesn't make sense to have their resolved beans available in the context. {% hint style="success" %} Understanding the purpose of many of the concepts exposed here is difficult without real use cases, please bear while we take you through [Creating the Context](https://docs.conanjs.io/dependency-injection/creating-the-context) and [Using the Context](https://docs.conanjs.io/dependency-injection/using-the-context) as things should start making sense soon! {% endhint %}