react-obsidian 0.0.32 → 0.0.33

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

@@ -0,0 +1,146 @@
+---
+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);
+  }
+}
+```
+
+## Typed dependencies
+The `DependenciesOf` utility type creates a type of 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
+type ApplicationDependencies = DependenciesOf<ApplicationGraph, 'httpClient' | 'databaseService'>; // {httpClient: httpClient, databaseService: DatabaseService}
+```
+
+## 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);
+  }
+}
+```

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

@@ -0,0 +1,85 @@
+---
+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});
+}
+```

package/documentation/docs/documentation/usage/ServiceLocator.mdx

@@ -0,0 +1,38 @@
+---
+sidebar_position: 5
+title: "Service locator"
+---
+
+## Obtaining dependencies imperatively
+
+Obsidian is an Inversion of Control container. This means that it will automatically resolve dependencies for you, and you don't need to worry about how to obtain them. However, there are times when you need to obtain a dependency imperatively, for example when you need to pass a dependency to a third-party library that doesn't support dependency injection.
+
+For these cases, you can obtain a graph instance and access the dependencies it provides imperatively. This is done by using the `Obsidian.obtain()` function which allows you to treat the graph as a Service Locator.
+
+### Example
+Consider the following graph which provides two dependencies: `fooService` and `barService` where `barService` depends on `fooService`:
+
+```ts
+import {Singleton, Graph, ObjectGraph, Provides} from 'react-obsidian';
+
+@Singleton() @Graph()
+export class SomeGraph extends ObjectGraph {
+  @Provides()
+  fooService(): FooService {
+    return new FooService();
+  }
+
+  @Provides()
+  barService(fooService: FooService): AppInitializer {
+    return new BarService(fooService);
+  }
+}
+```
+
+Obtaining the dependencies directly from the graph is straight forward:
+```ts Obtaining a dependency imperatively
+Obsidian.obtain(ApplicationGraph).fooService();
+
+// Even though barService depends on fooService, you don't need to provide its dependency
+Obsidian.obtain(ApplicationGraph).barService();
+```

package/documentation/docs/documentation/usage/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Usage",
+  "position": 2,
+  "collapsed": false,
+  "link": {
+    "type": "generated-index",
+    "description": "Learn how to inject hooks, components and classes with Obsidian."
+  }
+}

package/documentation/docs/guides/configurableApplications.mdx

@@ -0,0 +1,205 @@
+---
+sidebar_position: 2
+title: 'Configurable applications'
+toc_max_heading_level: 4
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+Designing applications to be flexible and configurable makes them more tolerable to changing requirements. The ability to change code frequently and quickly is one of the most important KPIs of any development team. This is generally made possible by a design that facilitates small pull requests, that modify a minimal amount of code across a minimal number of files.
+
+The Dependency Injection pattern helps us write flexible code that is more tolerable to change by addressing three key concerns:
+
+* How can a class be <ins>independent</ins> from the creation of the objects it depends on?
+* How can an application, and the objects it uses support different <ins>configurations</ins>?
+* How can the <ins>behavior</ins> of a piece of code be changed without editing it directly?
+
+In this article we will learn how Obsidian can help us address these concerns.
+
+## Configuring applications with providers
+When using Obsidian, dependencies are declared and constructed in classes called Graphs. Each dependency is constructed by a method called a provider which acts as a **Seam**. Lets see how we can leverage them to make our apps flexible and configurable.
+
+<!-- These providers act as **Seams**. -->
+
+:::tip What are Seams?
+A seam is a place where you can alter behavior in your program without editing in that place.
+
+[Working Effectively with Legacy Code](https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052) by Michael Feathers
+:::
+
+### Example 1: Interchangeable dependencies according to external configurations
+In this example we'll learn how to change the concrete object returned by a provider according to an external configuration. In a real life scenario, the external configuration would represent an A/B test or a feature toggle.
+
+#### Step 1: Declare a graph
+Lets declare a simple graph that provides a single dependency: an HTTP client used to make network requests.
+
+```ts
+@Singleton() @Graph()
+class ApplicationGraph extends ObjectGraph {
+  @Provides()
+  httpClient(): HttpClient {
+    return new HttpClient();
+  }
+}
+```
+
+Our `HttpClient` is using the standard `fetch` API to make network requests and for the sake of simplicity, it only supports `GET` and `POST` requests.
+
+```ts
+class HttpClient {
+  async get(url: string): Promise<any> {
+    const response = await fetch(url, { method: 'GET' });
+    return await response.json();
+  }
+
+  async post(url: string, body: any): Promise<any> {
+    const response = fetch(url, { method: 'POST', body: JSON.stringify(body) });
+    return await response.json();
+  }
+}
+```
+
+#### Step 2: Implement another HTTP client
+Just like our current HTTP client, the new client will only support `GET` and `POST` requests. The only difference is that it will use the `axios` library to make network requests.
+
+```ts
+class AxiosClient {
+  async get(url: string): Promise<any> {
+    const response = await axios.get(url);
+    return response.data;
+  }
+
+  async post(url: string, body: any): Promise<any> {
+    const response = await axios.post(url, body);
+    return response.data;
+  }
+}
+```
+
+#### Step 3: Make the clients interchangeable
+To easily switch between the two clients, we'll use a well known principle called [Dependency Inversion](https://en.wikipedia.org/wiki/Dependency_inversion_principle). This principle states that high-level modules should not depend on low-level modules. Both the `HttpClient` and the `AxiosClient` are low-level modules, so we'll make the `ApplicationGraph` depend on an abstraction called `NetworkClient` instead.
+
+```ts
+interface NetworkClient {
+  get(url: string): Promise<any>;
+  post(url: string, body: any): Promise<any>;
+}
+```
+
+The two network clients will implement this interface:
+<Tabs>
+  <TabItem value="http" label="HttpClient" default>
+
+```ts
+class HttpClient implements NetworkClient {
+  override async get(url: string): Promise<any> {
+    const response = await fetch(url, { method: 'GET' });
+    return await response.json();
+  }
+
+  override async post(url: string, body: any): Promise<any> {
+    const response = fetch(url, { method: 'POST', body: JSON.stringify(body) });
+    return await response.json();
+  }
+}
+```
+
+  </TabItem>
+  <TabItem value="axios" label="AxiosClient">
+
+```ts
+class AxiosClient implements NetworkClient {
+  override async get(url: string): Promise<any> {
+    const response = await axios.get(url);
+    return response.data.json;
+  }
+
+  override async post(url: string, body: any): Promise<any> {
+    const response = await axios.post(url, body);
+    return response.data.json;
+  }
+}
+```
+  </TabItem>
+</Tabs>
+
+#### Step 4: Return the correct client according to the configuration
+To determine which client to return, we'll use a new dependency called `AppConfig` which will be used to access the application's configuration.
+
+```ts
+@Singleton() @Graph()
+class ApplicationGraph extends ObjectGraph {
+  @Provides()
+  httpClient(appConfig: AppConfig): NetworkClient {
+    return appConfig.shouldUseAxiosClient() ? new AxiosClient() : new HttpClient();
+  }
+
+  @Provides()
+  appConfig(): AppConfig {
+    return new AppConfig();
+  }
+}
+```
+
+We're done! Now we can easily control which network client to use according the application's configuration.
+
+#### Conclusion and after thoughts
+In this example we learned how to make dependencies interchangeable, and how to control which dependency to use according to an external configuration. This is a very common use case in large scale applications where we need an extra layer of assurance that changes can be easily rolled back in case of a bug.
+
+Two important things to note about this example:
+1. The provider's return type was changed to `NetworkClient` instead of `HttpClient`. This change could lead to further changes in the codebase, but it's a small price to pay for the flexibility it provides.
+2.  We wanted to keep the example short and easy to follow, so the two HTTP clients are simplified implementations of an actual client. They also share the same API which made it easy to implement the `NetworkClient` interface and have the two clients implement it. If the two clients had different APIs, perhaps because they supported typed request options and responses, then we would have to create common interfaces that would represent the common parts of the two APIs and adapters that would convert the two clients' APIs to the common API and vice versa.
+
+### Example 2: Mocking dependencies in acceptance/integration tests
+Acceptance and integration tests are a great way to test how an application behaves as a whole. In these type of tests, objects aren't mocked since we're testing how the objects behave when they interact with each other. But because tests also need to be predictable and stable, there are some operations that we do want to simulate. For example, we might want to mock a network client so that we don't make real network requests during the test as that would add an unwanted layer of unpredictability to the test.
+
+In this example we'll learn how to mock a dependency and how to use that mocked instance across all objects involved in the test.
+
+#### Step 1: Declare a graph
+As in the previous example, we'll declare a simple graph that provides a single dependency: an HTTP client used to make network requests.
+
+```ts
+@Singleton() @Graph()
+export class ApplicationGraph extends ObjectGraph {
+  @Provides()
+  httpClient(): HttpClient {
+    return new HttpClient();
+  }
+}
+```
+
+#### Step 2: Mock the HTTP client
+To provide a mocked HTTP client to all objects involved in the test, we'll create a new graph that extends the `ApplicationGraph` and overrides the `httpClient` provider. In the next step we'll learn how to use this graph in our tests.
+
+```ts
+import { mock } from 'jest-mock-extended';
+
+@Singleton() @Graph()
+export class ApplicationGraphForTests extends ApplicationGraph {
+  @Provides()
+  override httpClient(): HttpClient {
+    return mock<HttpClient>();
+  }
+}
+```
+
+#### Step 3: Use the graph in the test
+To use the graph in the test, we'll use Obsidian's test kit to use the `ApplicationGraphForTests` instead of the `ApplicationGraph` whenever it's needed.
+
+```ts
+import {testKit} from 'react-obsidian';
+
+describe('Test suite', () => {
+  beforeEach(() => {
+    testKit.mockGraphs({
+      // Instruct Obsidian to use the ApplicationGraphForTests instead of the ApplicationGraph
+      ApplicationGraph: ApplicationGraphForTests,
+    });
+  });
+
+  it('should do something', () => {
+    // ...
+  });
+});
+```

package/documentation/docs/guides/mockDependencies.mdx

@@ -0,0 +1,141 @@
+---
+sidebar_position: 1
+title: 'Mocking dependencies in unit tests'
+---
+
+Tests are an integral part of any software project. They let you verify that your code works as expected and that it doesn't break when you make changes. We want our tests to be as clear as possible so that developers don't have to waste time figuring out what the test is doing our how to fix it when it fails.
+
+Obsidian promotes Object Oriented design, a paradigm that focuses on the relationships between objects and how they interact with each other. In this article we'll learn how adopting this approach lets us mock objects more easily and as a result improve the readability and maintainability of our tests.
+
+:::tip On readable tests and developer velocity
+"Every time the developers have to stop and puzzle through a test to figure out what it means, they have less time left to spend on creating new features, and the team velocity drops."
+
+— [Growing Object-Oriented Software, Guided by Tests](https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627)
+:::
+
+## The problem
+The setup phase of a test is often the most complex part of the test. It involves creating test data, mocking dependencies and instantiating the unit-under-test. We've identified three common problems that make tests brittle, difficult to maintain, and hard to understand:
+1. **Partial mocks** - a unit test is meant to test a single unit of code in isolation. If a dependency is partially mocked, our test is no longer testing a single unit. A bug in the partially mocked dependency can cause this unit test to fail preventing us from quickly identifying the root cause of the failure.
+2. **Dependencies are introduced implicitly to the unit-under-test, usually via imports** - we should always create valid objects. If an object depends on another object, we should pass that dependency explicity in through the constructor. The constructor serves as the contract for the dependencies that a class requires to function. There's no point in creating partially working classes, and the constructor is used to enforces this constraint.
+3. **Manual mocks** - manually mocking dependencies is a tedious and error prone process. It's easy to forget to mock a dependency, or to mock it incorrectly.
+
+To illustrate these problems, let's look at a simple example.
+
+```js showLineNumbers
+describe('Example', () => {
+  const openURL = jest.fn();
+
+  let logger;
+  let foo;
+  let uut;
+
+  beforeEach(() => {
+    // Problem 1: Partial mocks
+    logger = require('./Logger');
+    logger.log = jest.fn();
+    const spy = jest.spyOn(logger, 'warn');
+
+    // Problem 2: Implicit dependencies.
+    // Our UUT uses Linking.openUrl so we mock it on the module level.
+    jest.mock('react-native', () => ({
+      Linking: {
+        openURL  
+      },
+    }));
+    // Problem 3: Manual mocks
+    foo = {
+      doSomething: jest.fn(),
+    }
+    uut = new Example(logger, foo);
+  });
+});
+```
+
+## The solution
+To achieve our goal of reducing boilerplate and improving readability, we'll refactor the above example as follows:
+1. **Convert all dependencies to ES6 classes** - this will allow us to mock them using [jest-mock-extended](https://github.com/marchaos/jest-mock-extended) - a library that lets us create mock classes in a type-safe manner.
+2. **Pass dependencies in through the constructor** - we'll pass the dependencies explicitly to the unit-under-test. This step will require us to declare new classes that will encapsulate interactions with third-party libraries.
+
+<!-- In Object Oriented design, logic is encapsulated in classes that are introduced (injected) to one another in through the constructor.  -->
+<!-- This approach lets us use modern mocking techniques that require less boilerplate and are easier to reason about. -->
+<!-- To achieve our goal, we'll do two things:
+First, 
+First, refactor our code to use dependency injection. 
+
+
+To achieve our goal, we'll use an open-source library called [jest-mock-extended](https://github.com/marchaos/jest-mock-extended) which provides a `mock` function that creates a mock object with all the methods and properties of the original object. This means that we don't have to mock each method and property individually. -->
+
+### Step 1: Encapsulate interactions with third-party dependencies
+Implicit dependencies (dependencies introduced by importing a module) make it difficult to reason about the code and to test it. To avoid this problem, we'll create a new class that encapsulates interactions with the third-party library. We'll see how this approach lets us mock dependencies more easily.
+
+```ts title="Encapsulating the Linking module in a new class responsible for opening URLs"
+import {Linking} from 'react-native';
+
+export class UrlOpener {
+  public async openUrl(url: string) {
+    if (await Linking.canOpenURL(url)) {
+      await Linking.openURL(url);
+    } else {
+      throw new Error(`Can't open URL: ${url}`);
+    }
+  }
+}
+```
+
+:::tip On decoupling third party dependencies
+"Avoid littering direct calls to library classes in your code. You might think that you'll never change them, but that can become a self-fulfilling prophecy."
+
+— [Working Effectively with Legacy Code](https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052)
+:::
+
+### Step 2: Convert dependencies to ES6 classes
+We'll convert the `Logger` and `Foo` classes to ES6 classes:
+
+```ts title="Logger.ts"
+export class Logger {
+  public log(message: string) {
+    console.log(message);
+  }
+
+  public warn(message: string) {
+    console.warn(message);
+  }
+}
+```
+
+```ts title="Foo.ts"
+export class Foo {
+  public doSomething() {
+    console.log('doing something...');
+    setTimeout(() => {
+      console.log('done!');
+    }, 1000);
+  }
+}
+```
+
+### Step 3: Mock dependencies using jest-mock-extended
+When we mock a dependency using `jest-mock-extended`, we get a mock object that has all the methods and properties of the original object. This means that we don't have to mock each method and property individually. And, because we eliminated the implicit dependency on the `Linking` module, we can use this approach to mock it as well.
+
+```ts showLineNumbers
+import {mock} from 'jest-mock-extended';
+import {Logger} from './Logger';
+import {Foo} from './Foo';
+
+describe('Example', () => {
+  let logger: Logger;
+  let foo: Foo;
+  let urlOpener: UrlOpener;
+  let uut: Example;
+
+  beforeEach(() => {
+    logger = mock<Logger>();
+    foo = mock<Foo>();
+    urlOpener = mock<UrlOpener>();
+    uut = new Example(logger, foo, urlOpener);
+  });
+}
+```
+
+## Wrapping up
+While we didn't use any API from `Obsidian` in this refactor, this change was made possible due to how Obsidian influences the design of our code. Obsidian makes it easy to introduce classes to each other by passing them explicitly in through the constructor. This approach encourages us to split our code into smaller classes that are easier to test.