react-obsidian 1.1.0 → 1.2.0

package/documentation/docs/documentation/documentation.mdx

@@ -1,190 +0,0 @@
----
-sidebar_position: 1
----
-
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-
-# Introduction
-
-Obsidian is a dependency injection container with first-class support for React and React Native applications.
-
-Get started by **following the installation guide** bellow. Or **try Obsidian immediately** in the **[Online Playground](/playground)**.
-
-## The 2 steps tutorial for injecting dependencies with Obsidian
-
-### Step 1: Declare how dependencies should be created
-
-Define a singleton graph that is instantiated once and is retained throughout the lifespan of the application. All dependencies it provides are also singletons. The graph bellow provides two dependencies that can be injected: `fooService` and `barManager`.
-```ts title="A singleton graph that provides two dependencies"
-import {Singleton, Graph, ObjectGraph, Provides} from 'react-obsidian';
-
-
-@Singleton() @Graph()
-export class ApplicationGraph extends ObjectGraph {
-
- // fooService requires a barManager so it receives one as a parameter.
-  @Provides()
-  fooService(barManager: BarManager): FooService {
-    return new FooService(barManager);
-  }
-
-
-  @Provides()
-  barManager(): BarManager {
-    return new BarManager();
-  }
-}
-```
-
-### Step 2: Inject the dependencies
-Obsidian can inject dependencies into components, hooks, and classes.
-
-
-
-<Tabs>
-  <TabItem value="functionalComponent" label="Functional component injection" default>
-
-Injecting React functional components essentially revolves around two things: declaring the required dependencies in the components's props and exporting an injected component using the `injectComponent` function.
-
-```ts title="MyComponent.tsx"
-import {DependenciesOf, injectComponent} from 'react-obsidian';
-import {ApplicationGraph} from './ApplicationGraph';
-
-// 1. Declare which dependencies should be injected.
-type Props = DependenciesOf<ApplicationGraph, 'fooService'>; // {fooService: FooService}
-
-// 2. Implement the component.
-const myComponent = ({fooService}: Props) => {
-  // Do something useful with fooService
-}
-
-// 3. Export the injected component.
-export default injectComponent(myComponent, ApplicationGraph);
-```
-
-Now we can use the injected component without providing its dependencies manually:
-```tsx title="SomeComponent.tsx"
-import MyComponent from './MyComponent';
-
-const SomeComponent = () => {
-  // 4. Render the component - its dependencies are resolved automatically by Obsidian.
-  return <MyComponent />;
-}
-```
-  </TabItem>
-  <TabItem value="hook" label="Hook injection">
-
-Hooks are injected in a similar way to functional components. The only difference is that the `injectHook` function is used instead of `injectComponent`.
-
-```ts title="MyHook.ts"
-import {DependenciesOf, injectHook} from 'react-obsidian';
-import {ApplicationGraph} from './ApplicationGraph';
-
-// 1. Declare which dependencies should be injected.
-type Props = DependenciesOf<ApplicationGraph, 'fooService'>; // {fooService: FooService}
-
-// 2. Implement the hook.
-const myHook = ({fooService}: Props) => {
-  // Do something useful with fooService
-}
-
-// 3. Export the injected hook.
-export default injectHook(myHook, ApplicationGraph);
-```
-
-The injected hook can be used without providing its dependencies manually:
-```tsx title="SomeComponent.tsx"
-import myHook from './MyHook';
-
-const SomeComponent = () => {
-  // 4. Use the hook without providing any dependencies manually - they are injected automatically.
-  myHook();
-
-  return <>Obsidian is awesome!</>;
-}
-```
-  </TabItem>  
-  <TabItem value="classComponent" label="Class component injection">
-
-To inject a class, annotate it with the `@Injectable` decorator. The `@Injectable` decorator takes a single parameter - the graph that should be used to resolve the dependencies. Declare the dependencies as class members and annotate them with the `@Inject` decorator.
-
-```ts title="MyComponent.tsx"
-import {Injectable, Inject} from 'react-obsidian';
-import {ApplicationGraph} from './ApplicationGraph';
-
-@Injectable(ApplicationGraph)
-export MyClassComponent extends React.Component {
-  @Inject() private fooService!: FooService;
-
-}
-```
-
-Render the injected component. Obsidian resolves the required dependencies automatically.
-```tsx title="SomeComponent.tsx"
-import MyComponent from './MyComponent';
-
-const SomeComponent = () => {
-  // 4. Render the component - its dependencies are resolved automatically by Obsidian.
-  return <MyComponent />;
-}
-```
-
-  </TabItem>
-  <TabItem value="class" label="Class constructor injection">
-
-To inject a class, annotate it with the `@Injectable` decorator. The `@Injectable` decorator takes a single parameter - the graph that should be used to resolve the dependencies.
-Declare the dependencies as constructor parameters and annotate them with the `@Inject` decorator.
-
-```ts title="MyClass.tsx"
-import {Injectable, Inject} from 'react-obsidian';
-import {ApplicationGraph} from './ApplicationGraph';
-
-@Injectable(ApplicationGraph)
-export MyClass {
-  constructor (fooService?: FooService);
-  constructor(@Inject() private fooService: FooService) { }
-}
-```
-
-Now we can use the injected class without providing its dependencies manually:
-```ts
-const myClass = new MyClass();
-```
-
-Of course, passing dependencies explicitly is still possible:
-```ts
-const myClass = new MyClass(new FooService());
-```
-
-  </TabItem>
-</Tabs>
-
-___
-
-## Features
-
-* ⚛️ Inject all React constructs
-  * Functional components
-  * Hooks
-  * Class components
-* 🛠 Improve code structure
-  * Easily write object-oriented code with Single Responsibility in mind
-  * Eliminate circular dependencies
-  * Avoid implicit dependencies to make your code easier to reason about
-* ❤️ Developer experience
-  * Seamlessly integrates into existing projects
-  * Easy to adopt gradually
-  * Scales well
-  * Idiomatic API that's easy to understand
-
-## Design principles
-
-React Obsidian is guided by the principles of the Dependency Injection pattern, but does not strictly follow them. We allowed ourselves a degree of freedom when designing the library in order to reduce boilerplate code and library footprint.
-
-* **Easy to start** - Obsidian requires very little code to get you started. Once you declare a graph, using it to inject dependencies requires as little as two lines of code.
-* **Intuitive API** - The API should be verbose and understandable even to new users without prior experience with Dependency Injection.
-* **Minimal boilerplate** - Require the bare minimum in order to construct dependencies and resolve them. 
-
-<!-- ## Comparison with other libraries -->

package/documentation/docs/documentation/installation.mdx

@@ -1,56 +0,0 @@
----
-sidebar_position: 2
----
-
-# Installation
-
-Like most Dependency Injection frameworks, Obsidian uses automatic code generation to create the bindings necessary for resolving dependencies. This approach helps reduce the amount of boilerplate code required by developers. Obsidian relies on Babel for code generation, so you'll need to have Babel configured in your project.
-
-## 1. Install Obsidian
-
-```bash
-npm install react-obsidian
-```
-
-## 2. Install Reflect-metadata
-First, install and enable the reflect-metadata polyfill.
-```bash
-npm install reflect-metadata
-```
-
-Then, add the following line to the top of your application's entry point (usually index.js or index.ts):
-```js
-import 'reflect-metadata';
-```
-
-## 3. Enable experimental decorators
-Obsidian uses the Decorators feature whose proposal is at stage 3.
-
-Add the following options to your tsconfig.json file.
-
-```js
-{
-  "compilerOptions": {
-    "experimentalDecorators": true,
-    "emitDecoratorMetadata": true
-  }
-}
-```
-
-## 4. Add the required Babel plugins
-Add the transformer to the list of plugins in your `.babel` file.
-
-```diff
-module.exports = {
-  presets: [
-    'module:metro-react-native-babel-preset',
-+    ['@babel/preset-typescript', {'onlyRemoveTypeImports': true}]
-  ],
-  plugins: [
-+    react-obsidian/dist/transformers/babel-plugin-obsidian,
-+    ['@babel/plugin-proposal-decorators', {legacy: true}],
-+    '@babel/plugin-transform-class-properties',
-+    'babel-plugin-parameter-decorator'
-  ]
-};
-```

package/documentation/docs/documentation/meta/clearingGraphs.mdx

@@ -1,13 +0,0 @@
----
-sidebar_position: 2
-title: "Clearing graphs"
----
-
-Graphs can be cleared by invoking the `Obsidian.clearGraphs()` function. This is useful in tests or when you need to reset the system to it's original state, for example after a user logs out.
-
-#### Clearing graphs automatically during execution of Jest tests
-Create a `jest.setup.js` file and add it to [setupFilesAfterEnv](https://jestjs.io/docs/configuration#setupfilesafterenv-array). Then, import the following file when ensures graphs are cleared before each test.
-
-```js
-import 'react-obsidian/clearGraphs';
-```

package/documentation/docs/documentation/meta/middlewares.mdx

@@ -1,27 +0,0 @@
----
-sidebar_position: 1
-title: "Graph middlewares"
----
-
-Graph middlewares let you plug into the graph creation process and modify the graph in any way you want. This is useful when working on large scale applications where "observability" is a key concern. For example, you can use a middleware to swizzle providers, add logging, or even add a new provider to the graph.
-
-Middleware follow the Chain of Responsibility pattern and therefore must always return a graph, either by creating one explicitly or by returning the instance created by another member in the resolve chain.
-
-## Example: adding a logging middleware
-The following example demonstrates how to add a middleware that's used for logging purposes.
-
-```ts
-import { GraphMiddleware } from 'react-obsidian';
-
-const loggingMiddleware = new class extends GraphMiddleware {
-      resolve<Props>(resolveChain: GraphResolveChain, Graph: Constructable<T>, props?: Props) {
-        const t1 = Date.now();
-        const graph = resolveChain.proceed(Graph, props);
-        const t2 = Date.now();
-        console.log(`Graph created in ${t2 - t1} milliseconds`);
-        return graph;
-      }
-    }();
-
-Obsidian.addGraphMiddleware(loggingMiddleware);
-```

package/documentation/docs/documentation/usage/ClassComponents.mdx

@@ -1,18 +0,0 @@
----
-sidebar_position: 4
-title: "Class components"
----
-
-## Injecting class components
-Injecting class components is a two step process. First, annotate the class with the `@Injectable` annotation and pass the graph from which dependencies should be resolve. Then, declare the dependencies as class members and annotate them with the `@Inject` annotation.
-
-```ts
-import {Injectable, Inject} from 'react-obsidian';
-import {ApplicationGraph} from './ApplicationGraph';
-
-@Injectable(ApplicationGraph)
-export class ClassComponent extends React.Component {
-  @Inject() private httpClient!: HttpClient;
-  
-}
-```

package/documentation/docs/documentation/usage/Classes.mdx

@@ -1,41 +0,0 @@
----
-sidebar_position: 5
-title: "Classes"
----
-
-## Injecting classes
-Injecting classes is a two step process. First, annotate the class with the `@Injectable` annotation and pass the graph from which dependencies should be resolve. Then, declare the dependencies as class members and annotate them with the `@Inject` annotation.
-
-```ts
-import {Injectable, Inject} from 'react-obsidian';
-import {ApplicationGraph} from './ApplicationGraph';
-
-@Injectable(ApplicationGraph)
-export class MyClass {
-  @Inject() private httpClient!: HttpClient;
-  
-}
-```
-
-:::important Always prefer constructor injection over field injection
-Constructor injection is the preferred way to inject dependencies. It is more explicit and easier to test. **Field injection should only be used when a class is not instantiated by a graph.**
-:::
-
-## Delayed injection
-Dependencies annotated with the `@Inject` annotation are resolved immediately **after** the constructor is called. If you want to inject a class at a later point in time, you can use the `@LateInject` annotation instead, and inject the dependencies by manually with the `Obsidian.inject()` function.
-
-```ts
-import {Injectable, LateInject} from 'react-obsidian';
-import {ApplicationGraph} from './ApplicationGraph';
-
-@Injectable(ApplicationGraph)
-export class MyClass {
-  @LateInject() private httpClient!: HttpClient;
-
-  public init() {
-    console.log(this.httpClient === undefined); // true
-    Obsidian.inject(this);
-    console.log(this.httpClient === undefined); // false
-  }
-}
-```

package/documentation/docs/documentation/usage/FunctionalComponents.mdx

@@ -1,57 +0,0 @@
----
-sidebar_position: 3
-title: "Functional components"
----
-
-## Injecting functional components
-Component injection is identical in principle to how hooks are injected. The only difference is that instead of using the `injectHook` function, you use the `injectComponent` function. The `injectComponent` function takes the same arguments as the `injectHook` function, except that it takes a component as the second argument instead of a hook.
-
-```tsx title="Injecting a functional component"
-import { injectComponent, DependenciesOf } from 'react-obsidian';
-import { ApplicationGraph } from './ApplicationGraph';
-
-const MyComponent = ({httpService}: DependenciesOf<ApplicationGraph, 'httpClient'>) => {
-  return <div>My component</div>
-}
-
-export default injectComponent(MyComponent, ApplicationGraph);
-```
-
-:::tip Prefer injecting hooks over components
-Every entity (class, functional component etc.) in your application should have a single responsibility, and as such, there should be only one reason to change it. Components are responsible for rendering the UI, and therefor should change only when UI requirements change. 
-
-Prefer injecting hooks that will bridge between components and application logic. This allows components to emphasize "what" they need instead of "how", thus, preventing implementation details from leaking into them.
-:::
-
-## Strongly typed components
-The `injectComponent` function leverages *generics* to correctly type injected components.
-
-### Typing components that require props and injected dependencies
-In cases where a component requires both props and injected dependencies, we recommend typing them separately and declaring the component's props as the intersection of the two types. This way the component returned by the `injectComponent` function will require its `Own` props while all `Injected` dependencies will be marked as optional. `Injected` dependencies are marked as optional because they can either be injected manually or automatically by Obsidian.
-
-```tsx title="Separate declaration for passed (own) props and injected dependencies"
-import { injectComponent, DependenciesOf } from 'react-obsidian';
-import {ApplicationGraph} from './ApplicationGraph';
-
-type Injected = DependenciesOf<ApplicationGraph, 'httpClient'>;
-type Own = {name: string};
-
-const MyComponent = ({name, httpService}: Own & Injected) => {
-  return <div>Hey, my name is: {name} 👋</div>
-}
-
-// The result type is React.FunctionComponent<{name: string , httpClient?: HttpClient}>
-export default injectComponent<Own, Injected>(MyComponent, ApplicationGraph);
-```
-
-### Typing components that don't require Props
-If a component doesn't require any props from its parent component, simply use the `DependenciesOf` utility type provided by Obsidian to type the component's props. There's no need to use generics in this case as all props will are marked as optional.
-
-```tsx title="Typing components that don't require props"
-const MyComponent = ({httpService}: DependenciesOf<ApplicationGraph, 'httpClient'>) => {
-  return <div>Hello world 👋</div>
-}
-
-// The result type is React.FunctionComponent<{httpClient?: HttpClient}>
-export default injectComponent(MyComponent, ApplicationGraph);
-```

package/documentation/docs/documentation/usage/Graphs.mdx

@@ -1,154 +0,0 @@
----
-sidebar_position: 1
----
-
-## Introduction
-
-In Object Oriented Programming, programs are organized around objects, where each object has a specific purpose. These objects can require other objects to perform their responsibilities. The required objects are called dependencies. Providing these dependencies manually is a tedious and error-prone process. The dependency injection pattern is a way to automate this process so you can focus on the logic of your application instead of writing boilerplate code.
-
-Before you can inject dependencies into hooks, components and classes, the dependencies first need to be declared so Obsidian knows how to construct them. In Obsidian, dependencies are declared in classes called "Graphs". Graphs create a centralized place where dependencies are defined. This makes them a powerful tool for understanding the relationships between objects in your program.
-
-## Declaring dependencies in a graph
-The snippet below shows a basic example of a Graph. It defines two dependencies, `httpClient` and `databaseService`. 
-
-```ts title="ApplicationGraph.ts"
-import {Singleton, Graph, ObjectGraph, Provides} from 'react-obsidian';
-
-@Singleton() @Graph()
-export class ApplicationGraph extends ObjectGraph {
-  @Provides()
-  httpClient(): HttpClient {
-    return new HttpClient();
-  }
-
-  @Provides()
-  databaseService(): DatabaseService {
-    return new DatabaseService();
-  }
-}
-```
-
-Graphs must be annotated with the `@Graph` decorator. In this example we chose to annotate the class with the `@Singleton` decorator as well, which means that the graph and the dependencies it provides will only be constructed once.
-
-Dependencies are constructed in methods annotated with the `@Provides` annotation. The `@Provides` annotation is used to tell Obsidian that the method is a dependency provider. From now on we'll refer to these methods as providers. Obsidian uses the provider's method name as the dependency's name. In this example, the `httpClient` provider method provides the `httpClient` dependency. The `databaseService` provider method provides the `databaseService` dependency.
-
-Once your graph is declared you can use it to inject dependencies into the various constructs that form your application:
-* [Inject hooks](/docs/documentation/usage/hooks#injecting-hooks)
-* [Inject functional components](/docs/documentation/usage/FunctionalComponents)
-* [Inject components](/docs/documentation/usage/ClassComponents)
-* [Inject classes](/docs/documentation/usage/Classes)
-
-:::info Did you know?
-The term "graph" comes from [graph theory](https://en.wikipedia.org/wiki/Graph_theory). Obsidian constructs [Directed Acyclic Graphs](https://en.wikipedia.org/wiki/Directed_acyclic_graph) (DAGs) to represent the dependencies between objects. This type of graph ensures there are no circular dependencies between objects which cause call stack overflows and other unexpected bugs.
-:::
-
-## Specifying relationships between dependencies
-Some of the services defined in your graphs may be independent, meaning they don't require any dependencies to be constructed. However, most of the time, services will require other services to perform their responsibilities. In these cases, you can specify the dependencies of a service as arguments in the provider and Obsidian will resolve them automatically.
-
-```ts title="A graph that provides a service that depends on other services"
-import {Singleton, Graph, ObjectGraph, Provides} from 'react-obsidian';
-
-@Singleton() @Graph()
-export class ApplicationGraph extends ObjectGraph {
-  @Provides()
-  httpClient(): HttpClient {
-    return new HttpClient();
-  }
-
-  @Provides()
-  databaseService(): DatabaseService {
-    return new DatabaseService();
-  }
-
-  @Provides()
-  appInitializer(httpClient: HttpClient, databaseService: DatabaseService): AppInitializer {
-    return new AppInitializer(httpClient, databaseService);
-  }
-}
-```
-
-:::info
-Providers are evaluated lazily. This means that a provider is evaluated only when the dependency it provides is requested. Dependencies that are not used in the application, will never be constructed.
-:::
-
-## Graph types
-
-There are two types of graphs in Obsidian: A singleton graph and a lifecycle-bound graph.
-
-### The singleton graph
-Applications typically have at least one singleton graph. These graphs are used to provide dependencies that are used throughout the application. These dependencies are usually singletons, which means they should only be constructed once. The `ApplicationGraph` in the [example above](/docs/documentation/usage/Graphs#specifying-relationships-between-dependencies) is a singleton graph.
-
-To declare a singleton graph, annotate the graph class with the `@Singleton` decorator.
-
-### The lifecycle-bound graph
-Lifecycle-bound graphs are used to provide dependencies that are shared between components and hooks in a specific UI flow.
-
-Dependencies provided by a lifecycle-bound graph are treated as singletons within the scope of the components or hooks that depend on that graph. When a component or hook that depends on a lifecycle-bound graph is mounted, Obsidian will reuse an existing instance of the graph if one exists. If no instance of the graph exists, Obsidian will construct a new instance of the graph. Once all components or hooks that use the graph are unmounted, the graph is destroyed.
-
-In other words, dependencies provided by lifecycle-bound graphs are:
-1. Constructed and destroyed when the flow starts and ends.
-2. Shared between all components and hooks that take part in the flow.
-
-#### Passing props to a lifecycle-bound graph
-When a graph is created, it receives the props of the component or hook that requested it. This means that the graph can use the props to construct the dependencies it provides. The `@LifecycleBound` in the example below graph provides a `userService` which requires a `userId`. The `userId` is obtained from props.
-
-```ts title="A lifecycle-bound graph"
-import {LifecycleBound, Graph, ObjectGraph, Provides} from 'react-obsidian';
-
-type HomeScreenProps {
-  userId: string;
-}
-
-@LifecycleBound() @Graph()
-class HomeGraph extends ObjectGraph<HomeScreenProps> {
-  private userId: string;
-
-  construct(props: HomeScreenProps) {
-    super(props);
-    this.userId = props.userId;
-  }
-
-  @Provides()
-  userService(): UserService {
-    return new UserService(this.userId);
-  }
-}
-```
-
-## Graph composition
-Graph composition is a powerful feature that allows you to create complex dependency graphs by combining smaller graphs. Composing graphs is useful when you want to reuse a graph in multiple places. For example, you might have a singleton graph that provides application-level dependencies. You might also have a lifecycle-bound graph that provides dependencies for a specific UI flow. You can compose these graphs together so that the lifecycle-bound graph can also inject the dependencies provided by the singleton graph.
-
-To compose graphs, pass a `subgraphs` array to the `@Graph` decorator. The `subgraphs` array contains the graphs you want to "include" in your graph.
-
-In the example below we declared a lifecycle-bound graph called `LoginGraph`. This graph provides a single dependency called `loginService` which has a dependency on `httpClient`. Since `httpClient` is exposed via the `ApplicationGraph`, we included it in the `subgraphs` array of our graph.
-
-
-```ts title="LoginGraph.ts"
-import {Graph, ObjectGraph, Provides} from 'react-obsidian';
-import {ApplicationGraph} from './ApplicationGraph';
-
-@LifecycleBound() @Graph({subgraphs: [ApplicationGraph]}) 
-export class LoginGraph extends ObjectGraph {
-  @Provides()
-  loginService(httpClient: HttpClient): LoginService {
-    return new LoginService(httpClient);
-  }
-}
-```
-
-## Typed dependencies
-The `DependenciesOf` utility type creates a new type consisting the dependencies provided by a graph. This type can be used to type the dependencies of hooks or props required by components. This utility type takes two arguments: the graph and a union of the keys of the dependencies we want to inject.
-
-In this example we create a type called `ApplicationDependencies` which contains the dependencies `httpClient` and `databaseService` from the `ApplicationGraph` graph.
-
-```ts
-// {httpClient: HttpClient, databaseService: DatabaseService}
-type Dependencies = DependenciesOf<ApplicationGraph, 'httpClient' | 'databaseService'>;
-```
-
-In cases where a graph has subgraphs, we can pass an array of graphs to the `DependenciesOf` utility type to create a type that contains the dependencies from all the graphs. Using the `LoginGraph` from the example above, we create a type that contains dependencies from both the `LoginGraph` and the `ApplicationGraph`:
-
-```ts
-// {httpClient: HttpClient, loginService: LoginService}
-type Dependencies = DependenciesOf<[LoginGraph, ApplicationGraph], 'httpClient' | 'loginService'>;
-```

package/documentation/docs/documentation/usage/Hooks.mdx

@@ -1,85 +0,0 @@
----
-sidebar_position: 2
----
-
-## Injecting hooks
-
-Hooks are a fundamental construct in React. They allow you to plug into the lifecycle of a component or react to user interaction and execute code accordingly. As such, hooks typically need to interact with services where the actual logic is implemented.
-
-Injecting hooks is simple and straightforward. Simply wrap your hook with the `injectHook` function and declare any required dependencies as destructured properties.
-
-```tsx
-import { injectHook, DependenciesOf } from 'react-obsidian';
-import { ApplicationGraph } from './ApplicationGraph';
-
-const myHook = ({fooService, barService}: Props) => {
-  // do something with fooService and barService
-}
-
-type Props = DependenciesOf<ApplicationGraph, 'fooService' | 'barService'>; // {fooService: FooService, barService: BarService}
-
-export injectHook(myHook, ApplicationGraph);
-```
-
-## Strongly typed hooks
-Writing strongly typed hooks is important to ensure that your hooks are easy to use and that you don't accidentally break them when refactoring. 
-
-### Combining injected dependencies and required arguments
-Sometimes you want to inject hooks with dependencies, but also require additional arguments that will be passed from the calling scope. This is possible by using the `injectHookWithArguments` function.
-
-```tsx
-import { injectHook, DependenciesOf } from 'react-obsidian';
-import { ApplicationGraph } from './ApplicationGraph';
-
-type Injected = DependenciesOf<ApplicationGraph, 'fooService'>; // {fooService: FooService}
-type Own = {count: number};
-
-const myHook = ({fooService, count}: Injected & Own) => {
-  // do something with fooService and count
-}
-
-export default injectHookWithArguments<Injected, Own>(myHook, ApplicationGraph);
-```
-
-When using `myHook`, we must pass the `count` argument otherwise we will get a type error. `fooService`, on the other hand, is optional and will be injected from the graph unless passed explicitly.
-
-```tsx
-import myHook from './myHook';
-
-const MyComponent = () => {
-  const [count, setCount] = useState(1337);
-  myHook({count}); 
-  
-}
-```
-
-### Typing the return value of a hook
-When using the standard `injectHook` function, the return value of the hook is inferred automatically by TypeScript. However, when using `injectHookWithArguments`, due to limitations of TypeScript's Generics system, the return value is not inferred and you'll have to specify it explicity.
-
-```ts
-import { injectHook, DependenciesOf } from 'react-obsidian';
-import { ApplicationGraph } from './ApplicationGraph';
-
-type Injected = DependenciesOf<ApplicationGraph, 'fooService'>;
-type Own = {count: number};
-type Result: {onPress: () => void};
-
-const myHook = ({fooService, count}: Injected & Own): Result => {
-  const onPress = useCallback(() => {
-    fooService.doSomething(count);
-  }, [fooService, count]);
-  return {onPress};
-}
-
-export default injectHookWithArguments<Injected, Own, Result>(myHook, ApplicationGraph);
-```
-
-Now the onPress callback is typed correctly when using the injected hook.
-```tsx
-import myHook from './myHook';
-
-const MyComponent = () => {
-  const [count, setCount] = useState(1337);
-  const {onPress} = myHook({count});
-}
-```