From 1ca13946003db64561e6e53ae20c0dceb4859e5e Mon Sep 17 00:00:00 2001 From: Andrew Croome Date: Tue, 11 Oct 2022 18:24:49 +1100 Subject: [PATCH] Fix ups. --- docs/application-architecture/containers.md | 6 +++--- docs/application-architecture/providers.md | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/application-architecture/containers.md b/docs/application-architecture/containers.md index c6df4a4..88f589b 100644 --- a/docs/application-architecture/containers.md +++ b/docs/application-architecture/containers.md @@ -6,11 +6,11 @@ sidebar_position: 1 In Hanami, the application code you add to your `/app` directory is automatically organised into a container. This container forms the basis of a depenency injection system, in which the dependencies of the components you create are provided to them automatically. -Let's take a look at what this means in practice. +Let's take a look at how this works in practice. Imagine we're building a Bookshelf notifications service for sending notifications to users of the Bookshelf platform. After running `hanami new notifications_service`, our first task is to send welcome emails. To achieve this, we want to provide a `POST /welcome-emails` action that will send a welcome email, probably via a send welcome operation, which in turn will want to render our email in both html and plain text. -As a first pass, we might add four Ruby classes to our `/app` folder - our action, operation, and two renderers. +As a first pass, we might add four Ruby classes to our `app` folder - our action, operation, and two renderers. On the file system, this might look like: @@ -28,7 +28,7 @@ app └── text.rb ``` -When our application boots, Hanami will automatically create instances of these components and register them in its __app container__, under a key based on their Ruby namespace. +When our application boots, Hanami will automatically create __instances__ of these components and register them in its __app container__, under a key based on their Ruby namespace. For example, an instance of our `NotificationsService::Emails::Welcome::Operations::Send` class will be registered under the key `"emails.welcome.operations.send"`. diff --git a/docs/application-architecture/providers.md b/docs/application-architecture/providers.md index dfacbbc..a72d944 100644 --- a/docs/application-architecture/providers.md +++ b/docs/application-architecture/providers.md @@ -4,13 +4,13 @@ sidebar_position: 2 # Providers -Providers are a way to register components with your containers, outside of the automatic registration mechanism detailed in [containers and depenencies](/docs/application-structure/containers). +Providers are a way to register components with your containers, outside of the automatic registration mechanism detailed in [containers and dependencies](/docs/application-architecture/containers). Providers are useful when: -- you need to set up a dependency that requires non-trivial configuration (often a third party library, or some library-like code in your `/lib` directory) +- you need to set up a dependency that requires non-trivial configuration (often a third party library, or some library-like code in your `lib` directory) - you want to take advantage of provider lifecycle methods (prepare, start and stop) -- you want to share a component across both your app container and the containers of all your [slices](/docs/application-structure/slices). +- you want to share a component across both your app container and the containers of all your [slices](/docs/application-architecture/slices). App-level providers should be placed in the `config/providers` directory. Slices can have their own providers also, placed in `slices/my_slice/providers`.