Merge pull request #328 from inversify/feat/update-next-dependency-in…

…jection-docs-page

Update next dependency injection docs page

packages/docs/services/inversify-site/docs/api/binding-syntax.mdx

@@ -15,7 +15,7 @@ import CodeBlock from '@theme/CodeBlock';
 
 # Binding Syntax
 
-Binding syntax is provided as a fluent interface resulting from using the [container API](/docs/api/container#bind) or the [container module API](/docs/api/container-module#bind).
+Binding syntax is provided as a fluent interface resulting from using the [container API](./container.mdx#bind) or the [container module API](./container-module.mdx#bind).
 
 ## BindToFluentSyntax
 
@@ -133,23 +133,23 @@ Represents a service binding given a service identifier and a service resolution
 inSingletonScope(): BindWhenOnFluentSyntax<T>;
 ```
 
-Sets the binding scope to singleton. Refer to the [docs](/docs/fundamentals/binding#singleton) for more information.
+Sets the binding scope to singleton. Refer to the [docs](../fundamentals/binding.mdx#singleton) for more information.
 
 ### inTransientScope
 
 ```ts
 inTransientScope(): BindWhenOnFluentSyntax<T>;
 ```
 
-Sets the binding scope to transient. Refer to the [docs](/docs/fundamentals/binding#transient) for more information.
+Sets the binding scope to transient. Refer to the [docs](../fundamentals/binding.mdx#transient) for more information.
 
 ### inRequestScope
 
 ```ts
 inRequestScope(): BindWhenOnFluentSyntax<T>;
 ```
 
-Sets the binding scope to request. Refer to the [docs](/docs/fundamentals/binding#request) for more information.
+Sets the binding scope to request. Refer to the [docs](../fundamentals/binding.mdx#request) for more information.
 
 ## BindOnFluentSyntax
 

packages/docs/services/inversify-site/docs/api/container-module.mdx

@@ -37,44 +37,44 @@ Options to be passed to the load callback. It contains the following properties:
 bind: <T>(serviceIdentifier: ServiceIdentifier<T>) => BindToFluentSyntax<T>
 ```
 
-Refer to the [docs](/docs/api/container#bind) for more information.
+Refer to the [docs](./container.mdx#bind) for more information.
 
 ### isBound
 
 ```ts
 isBound: (serviceIdentifier: ServiceIdentifier, options?: IsBoundOptions) => boolean
 ```
 
-Refer to the [docs](/docs/api/container#isbound) for more information.
+Refer to the [docs](./container.mdx#isbound) for more information.
 
 ### onActivation
 
 ```ts
 onActivation: <T>(serviceIdentifier: ServiceIdentifier<T>, activation: BindingActivation<T>) => void
 ```
 
-Refer to the [docs](/docs/api/container#onactivation) for more information.
+Refer to the [docs](./container.mdx#onactivation) for more information.
 
 ### onDeactivation
 
 ```ts
 onDeactivation: <T>(serviceIdentifier: ServiceIdentifier<T>, deactivation: BindingDeactivation<T>) => void
 ```
 
-Refer to the [docs](/docs/api/container#ondeactivation) for more information.
+Refer to the [docs](./container.mdx#ondeactivation) for more information.
 
 ### unbind
 
 ```ts
 unbind: (serviceIdentifier: ServiceIdentifier) => Promise<void>
 ```
 
-Refer to the [docs](/docs/api/container#unbind) for more information.
+Refer to the [docs](./container.mdx#unbind) for more information.
 
 ## Example: binding services through ContainerModule API
 
 When a container module is loaded into a Container, the load callback is invoked. This is the opportunity for the container module to register bindings and handlers.
 
-When a container module is unloaded from a Container, the bindings added by that container will be removed, and the [deactivation process](/docs/fundamentals/lifecycle/deactivation) will occur for each of them. Container deactivation and [activation handlers](/docs/fundamentals/lifecycle/activation) will also be removed.
+When a container module is unloaded from a Container, the bindings added by that container will be removed, and the [deactivation process](../fundamentals/lifecycle/deactivation.mdx) will occur for each of them. Container deactivation and [activation handlers](../fundamentals/lifecycle/activation.mdx) will also be removed.
 
 <CodeBlock language="ts">{containerModuleApiExampleSource}</CodeBlock>

packages/docs/services/inversify-site/docs/api/container.mdx

@@ -33,7 +33,7 @@ Options can be changed after construction and will be shared by child containers
 parent?: Container | undefined;
 ```
 
-The parent container, if any. Refer to the [container hierarchy docs](/docs/fundamentals/di-hierarchy) for more information.
+The parent container, if any. Refer to the [container hierarchy docs](../fundamentals/di-hierarchy.mdx) for more information.
 
 ### defaultScope
 
@@ -120,7 +120,7 @@ You can use the `isCurrentBound` method to check if there are registered binding
 load(...modules: ContainerModule[]): Promise<void>;
 ```
 
-Calls the registration method of each module. See [ContainerModule API docs](/docs/api/container-module).
+Calls the registration method of each module. See [ContainerModule API docs](./container-module.mdx).
 
 ## onActivation
 
@@ -148,37 +148,37 @@ Adds a deactivation handler for a service identifier.
 restore(): void;
 ```
 
-Restore container state to last snapshot. Refer to the [docs](/docs/fundamentals/snapshot) for more information.
+Restore container state to last snapshot. Refer to the [docs](../fundamentals/snapshot.mdx) for more information.
 
 ## snapshot
 
 ```ts
 snapshot(): void;
 ```
 
-Save the state of the container to be later restored with the restore method. Refer to the [docs](/docs/fundamentals/snapshot) for more information.
+Save the state of the container to be later restored with the restore method. Refer to the [docs](../fundamentals/snapshot.mdx) for more information.
 
 ## unbind
 
 ```ts
 unbind(serviceIdentifier: ServiceIdentifier): Promise<void>;
 ```
 
-Remove all bindings binded in this container to the service identifier. This will result in the [deactivation process](/docs/fundamentals/lifecycle/deactivation).
+Remove all bindings binded in this container to the service identifier. This will result in the [deactivation process](../fundamentals/lifecycle/deactivation.mdx).
 
 ## unbindAll
 
 ```ts
 unbindAll(): Promise<void>;
 ```
 
-Remove all bindings binded in this container.  This will result in the [deactivation process](/docs/fundamentals/lifecycle/deactivation).
+Remove all bindings binded in this container.  This will result in the [deactivation process](../fundamentals/lifecycle/deactivation.mdx).
 
 ## unload
 
 ```ts
 unload(...modules: ContainerModule[]): Promise<void>;
 ```
 
-Removes bindings and handlers added by the modules. This will result in the [deactivation process](/docs/fundamentals/lifecycle/deactivation).
-See [ContainerModule API docs](/docs/api/container-module).
+Removes bindings and handlers added by the modules. This will result in the [deactivation process](../fundamentals/lifecycle/deactivation.mdx).
+See [ContainerModule API docs](./container-module.mdx).

packages/docs/services/inversify-site/docs/api/decorator.mdx

@@ -87,7 +87,7 @@ This time, no class metadata is emitted even if the `emitDecoratorMetadata` Type
 
 Decorator used to establish a relation between a constructor argument or a class property and a service ID.
 
-When resolving an instance of the class, the target constructor argument or property will be resolved in the same way [container.get](/docs/api/container#get) behaves.
+When resolving an instance of the class, the target constructor argument or property will be resolved in the same way [container.get](./container.mdx#get) behaves.
 
 ### Example: decorating a class constructor argument
 
@@ -101,7 +101,7 @@ When resolving an instance of the class, the target constructor argument or prop
 
 Decorator used to establish a relation between a constructor argument or a class property and a service ID.
 
-When resolving an instance of the class, the target constructor argument or property will be resolved in the same way [container.getAll](/docs/api/container#getall) behaves.
+When resolving an instance of the class, the target constructor argument or property will be resolved in the same way [container.getAll](./container.mdx#getall) behaves.
 
 ### Example: decorating a property
 
@@ -121,13 +121,13 @@ Decorator used to establish that a target constructor argument or property is op
 
 ## postConstruct
 
-Decorator used to establish an activation handler for the target class. Refer to the [docs](/docs/fundamentals/lifecycle/activation) for more information.
+Decorator used to establish an activation handler for the target class. Refer to the [docs](../fundamentals/lifecycle/activation.mdx) for more information.
 
 <CodeBlock language="ts">{decoratorApiPostConstructSource}</CodeBlock>
 
 ## preDestroy
 
-Decorator used to establish a deactivation handler for the target class. Refer to the [docs](/docs/fundamentals/lifecycle/deactivation) for more information.
+Decorator used to establish a deactivation handler for the target class. Refer to the [docs](../fundamentals/lifecycle/deactivation.mdx) for more information.
 
 <CodeBlock language="ts">{decoratorApiPreDestroySource}</CodeBlock>
 

packages/docs/services/inversify-site/docs/fundamentals/binding.mdx

@@ -48,8 +48,8 @@ When the service is resolved, a new resolved value will be used each time.
 
 ### Constraint
 
-Specifies whether the binding is used to provide a resolved value for the given service identifier. Refer to the [API docs](/docs/api/binding-syntax#bindingwhensyntax) for more information.
+Specifies whether the binding is used to provide a resolved value for the given service identifier. Refer to the [API docs](../api/binding-syntax.mdx#bindwhenfluentsyntax) for more information.
 
 ### Lifecycle handlers
 
-Handlers that are called after a resolved value is provided or a singleton-scoped binding is deactivated. Refer to the [API docs](/docs/api/binding-syntax#bindingonsyntax) for more information.
+Handlers that are called after a resolved value is provided or a singleton-scoped binding is deactivated. Refer to the [API docs](../api/binding-syntax.mdx#bindonfluentsyntax) for more information.

packages/docs/services/inversify-site/docs/fundamentals/inheritance.mdx

@@ -4,49 +4,5 @@ title: Inheritance
 ---
 # Inheritance
 
-Inheritance can be achieved as long as constructor parameters are properly decorated. There are two ways to ensure this:
+Inheritance can be achieved relying on the `@injectFromBase` decorator. This decorator allows you to inject dependencies from the base class constructor.
 
-- The number of decorated constructor arguments in a derived class is greater than or equal to the number of constructor arguments in its base class.
-- The [skipBaseClassChecks](/docs/api/container#skipbaseclasschecks) option is enabled.
-
-## Example of incorrect inheritance injection
-
-```ts
-@injectable()
-class Warrior {
-  public rank: string;
-  constructor(rank: string) { // args count = 1
-    this.rank = rank;
-  }
-}
-
-@injectable()
-class SamuraiMaster extends Warrior {
-  constructor() { // args count = 0
-    super("master");
-  }
-}
-```
-
-When trying to get a `SamuraiMaster`, the container throws an error indicating that the constructor parameters are not properly decorated.
-
-## Using the @unmanaged decorator
-
-The [unmanaged](/docs/api/decorator#unmanaged) decorator tells Inversify that a base type constructor parameter should not be managed. This is often the case when dealing with inheritance hierarchies where only leaf types are injected.
-
-```ts
-@injectable()
-class Warrior {
-  public rank: string;
-  constructor(@unmanaged() rank: string) { // args count = 0, unmanaged args are not included
-    this.rank = rank;
-  }
-}
-
-@injectable()
-class SamuraiMaster extends Warrior {
-  constructor() { // args count = 0
-    super("master");
-  }
-}
-```

packages/docs/services/inversify-site/docs/fundamentals/lifecycle/activation.mdx

@@ -11,9 +11,9 @@ Whenever a service is resolved, the activation event is dispatched. An activatio
 
 There are multiple ways to provide an activation handler
 
-- Adding the handler to the [container](/docs/api/container#onactivation).
-- Adding the handler to the [binding](/docs/api/binding-syntax#onactivation).
-- Adding the handler to the class through the [postConstruct decorator](/docs/api/decorator#postconstruct).
+- Adding the handler to the [container](../../api/container.mdx#onactivation).
+- Adding the handler to the [binding](../../api/binding-syntax.mdx#onactivation).
+- Adding the handler to the class through the [postConstruct decorator](../../api/decorator.mdx#postconstruct).
 
 When multiple activation handlers are binded to a service identifier, the `postConstruct` handler is called before any others. After that, the binding handler is called. Then, container handlers are called, starting at the root container and descending the descendant containers stopping at the container with the binding.
 

packages/docs/services/inversify-site/docs/fundamentals/lifecycle/deactivation.mdx

@@ -11,8 +11,8 @@ Whenever a singleton scoped service is unbound, the deactivation event is dispat
 
 It's possible to add a deactivation handler in multiple ways
 
-- Adding the handler to the [container](/docs/api/container#ondeactivation).
-- Adding the handler to a [binding](/docs/api/binding-syntax#ondeactivation).
-- Adding the handler to the class through the [preDestroy decorator](/docs/api/decorator#predestroy).
+- Adding the handler to the [container](../../api/container.mdx#ondeactivation).
+- Adding the handler to a [binding](../../api/binding-syntax.mdx#ondeactivation).
+- Adding the handler to the class through the [preDestroy decorator](../../api/decorator.mdx#predestroy).
 
 Handlers added to the container are the first ones to be resolved. Any handler added to a child container is called before the ones added to their parent. Relevant bindings from the container are called next and finally the `preDestroy` method is called. In the example above, relevant bindings are those bindings bound to the unbinded "Destroyable" service identifier.