Aktueller Stand

backend/node_modules/fastify/docs/Reference/Encapsulation.md

@@ -3,21 +3,20 @@
 ## Encapsulation
 <a id="encapsulation"></a>
 
-A fundamental feature of Fastify is the "encapsulation context." The
-encapsulation context governs which [decorators](./Decorators.md), registered
-[hooks](./Hooks.md), and [plugins](./Plugins.md) are available to
-[routes](./Routes.md). A visual representation of the encapsulation context
-is shown in the following figure:
+A fundamental feature of Fastify is the "encapsulation context." It governs
+which [decorators](./Decorators.md), registered [hooks](./Hooks.md), and
+[plugins](./Plugins.md) are available to [routes](./Routes.md). A visual
+representation of the encapsulation context is shown in the following figure:
 
 ![Figure 1](../resources/encapsulation_context.svg)
 
-In the above figure, there are several entities:
+In the figure above, there are several entities:
 
 1. The _root context_
 2. Three _root plugins_
-3. Two _child contexts_ where each _child context_ has
+3. Two _child contexts_, each with:
     * Two _child plugins_
-    * One _grandchild context_ where each _grandchild context_ has
+    * One _grandchild context_, each with:
         - Three _child plugins_
 
 Every _child context_ and _grandchild context_ has access to the _root plugins_.
@@ -26,15 +25,18 @@ _child plugins_ registered within the containing _child context_, but the
 containing _child context_ **does not** have access to the _child plugins_
 registered within its _grandchild context_.
 
-Given that everything in Fastify is a [plugin](./Plugins.md), except for the
+Given that everything in Fastify is a [plugin](./Plugins.md) except for the
 _root context_, every "context" and "plugin" in this example is a plugin
-that can consist of decorators, hooks, plugins, and routes. Thus, to put
-this example into concrete terms, consider a basic scenario of a REST API
-server that has three routes: the first route (`/one`) requires authentication,
-the second route (`/two`) does not, and the third route (`/three`) has
-access to the same context as the second route. Using
-[@fastify/bearer-auth][bearer] to provide the authentication, the code for this
-example is as follows:
+that can consist of decorators, hooks, plugins, and routes. As plugins, they
+must still signal completion either by returning a Promise (e.g., using `async`
+functions) or by calling the `done` function if using the callback style.
+
+To put this
+example into concrete terms, consider a basic scenario of a REST API server
+with three routes: the first route (`/one`) requires authentication, the
+second route (`/two`) does not, and the third route (`/three`) has access to
+the same context as the second route. Using [@fastify/bearer-auth][bearer] to
+provide authentication, the code for this example is as follows:
 
 ```js
 'use strict'
@@ -52,9 +54,9 @@ fastify.register(async function authenticatedContext (childServer) {
     handler (request, response) {
       response.send({
         answer: request.answer,
-        // request.foo will be undefined as it's only defined in publicContext
+        // request.foo will be undefined as it is only defined in publicContext
         foo: request.foo,
-        // request.bar will be undefined as it's only defined in grandchildContext
+        // request.bar will be undefined as it is only defined in grandchildContext
         bar: request.bar
       })
     }
@@ -71,7 +73,7 @@ fastify.register(async function publicContext (childServer) {
       response.send({
         answer: request.answer,
         foo: request.foo,
-        // request.bar will be undefined as it's only defined in grandchildContext
+        // request.bar will be undefined as it is only defined in grandchildContext
         bar: request.bar
       })
     }
@@ -97,16 +99,16 @@ fastify.register(async function publicContext (childServer) {
 fastify.listen({ port: 8000 })
 ```
 
-The above server example shows all of the encapsulation concepts outlined in the
+The server example above demonstrates the encapsulation concepts from the
 original diagram:
 
 1. Each _child context_ (`authenticatedContext`, `publicContext`, and
-`grandchildContext`) has access to the `answer` request decorator defined in
-the _root context_.
+   `grandchildContext`) has access to the `answer` request decorator defined in
+   the _root context_.
 2. Only the `authenticatedContext` has access to the `@fastify/bearer-auth`
-plugin.
+   plugin.
 3. Both the `publicContext` and `grandchildContext` have access to the `foo`
-request decorator.
+   request decorator.
 4. Only the `grandchildContext` has access to the `bar` request decorator.
 
 To see this, start the server and issue requests:
@@ -125,16 +127,13 @@ To see this, start the server and issue requests:
 ## Sharing Between Contexts
 <a id="shared-context"></a>
 
-Notice that each context in the prior example inherits _only_ from the parent
-contexts. Parent contexts cannot access any entities within their descendent
-contexts. This default is occasionally not desired. In such cases, the
-encapsulation context can be broken through the usage of
-[fastify-plugin][fastify-plugin] such that anything registered in a descendent
-context is available to the containing parent context.
+Each context in the prior example inherits _only_ from its parent contexts. Parent
+contexts cannot access entities within their descendant contexts. If needed,
+encapsulation can be broken using [fastify-plugin][fastify-plugin], making
+anything registered in a descendant context available to the parent context.
 
-Assuming the `publicContext` needs access to the `bar` decorator defined
-within the `grandchildContext` in the previous example, the code can be
-rewritten as:
+To allow `publicContext` access to the `bar` decorator in `grandchildContext`,
+rewrite the code as follows:
 
 ```js
 'use strict'