Apply suggestions from code review

Co-authored-by: Rodrigo Lazo <[email protected]>

Author: vkryachko

contributor-docs/components/dependencies.md

@@ -8,19 +8,19 @@ parent: Firebase Components
 1. TOC
 {:toc}
 
-This page gives an overview of various different dependency types supported by the Components Framework.
+This page gives an overview of the different dependency types supported by the Components Framework.
 
 ## Background
 
 As discussed in [Firebase Components]({{ site.baseurl }}{% link components/components.md %}), in order
-for a `Component` to be injected with the things it needs to function, it needs to declare dependencies.
+for a `Component` to be injected with the things it needs to function, it has to declare its dependencies.
 These dependencies are then made available and injected into `Components` at runtime.
 
-Firebase Components provide different types of dependencies
+Firebase Components provide different types of dependencies.
 
 ## Lazy vs Eager dependencies
 
-When it comes to initializing a given component, there are 2 ways to provide its dependencies to it.
+When it comes to initialize a component, there are 2 ways of provide its dependencies.
 
 ### Direct Injection
 
@@ -35,14 +35,14 @@ class MyComponent(private val dep : MyDep) {
 ```
 
 As you can see above the component's dependency is passed by value directly,
-which means that the dependency component needs to have fully initialized before
+which means that the dependency needs to be fully initialized before
 it's handed off to the requesting component. As a result `MyComponent` may have to pay the cost
-of `MyDep` initialization just to be able to be created.
+of initializing `MyDep` just to be created.
 
 ### Lazy/Provider Injection
 
-With this type of injection, instead of getting and instance of the dependency directly, the dependency
-is passed into the `Component` with the help of the `com.google.firebase.inject.Provider`
+With this type of injection, instead of getting an instance of the dependency directly, the dependency
+is passed into the `Component` with the help of a `com.google.firebase.inject.Provider`
 
 ```java
 public interface Provider<T> { T get(); }
@@ -58,17 +58,17 @@ class MyComponent(private val dep : Provider<MyDep>) {
 }
 ```
 
-On the surface this does not look like a big change, but it has an important side effect where,
-in order to create an instance of `MyComponent`, there is no need to initialize `MyDep` and instead
-to delay it until it's actually needed.
+On the surface this does not look like a big change, but it has an important side effect. In order to create
+an instance of `MyComponent`, we don't need to initialize `MyDep` anymore. Instead, initialization can be
+delayed until `MyDep` is actually used.
 
 It is also benefitial to use a `Provider` in the context of [Play's dynamic feature delivery](https://developer.android.com/guide/playcore/feature-delivery).
 See [Dynamic Module Support]({{ site.baseurl }}{% link components/dynamic_modules.md %}) for more details.
 
 ## Required dependencies
 
 This type of dependency informs the `ComponentRuntime` that a given `Component` cannot function without a dependency.
-When the dependency is missing during initialization, `ComponentRuntime` will throw a `DependencyMissingDependency`.
+When the dependency is missing during initialization, `ComponentRuntime` will throw a `MissingDependencyException`.
 This type of dependency is useful for built-in components that are always present like `Context`, `FirebaseApp`,
 `FirebaseOptions`, [Executors]({{ site.baseurl }}{% link components/executors.md %}).
 
@@ -89,7 +89,7 @@ This type of dependencies is useful when your `Component` can operate normally w
 available, but can have enhanced functionality when present. e.g. `Firestore` can work without `Auth` but
 provides secure database access when `Auth` is present.
 
-To declare a required dependency use the following in your `ComponentRegistrar`:
+To declare an optional dependency use the following in your `ComponentRegistrar`:
 
 ```java
   .add(Dependency.optionalProvider(MyDep.class))
@@ -101,19 +101,18 @@ The provider will return `null` if the dependency is not present in the app.
 
 {: .warning }
 When the app uses [Play's dynamic feature delivery](https://developer.android.com/guide/playcore/feature-delivery),
-`provider.get()` can return your dependency when it becomes available, so be prepared for that.
-And don't store references to the result of `provider.get()` calls.
+`provider.get()` will return your dependency when it becomes available.  To support this use case, don't store references to the result of `provider.get()` calls.
 
 See [Dynamic Module Support]({{ site.baseurl }}{% link components/dynamic_modules.md %}) for details
 
 {: .warning }
-See Deferred dependencies if you your dependency has a callback based apis
+See Deferred dependencies if you your dependency has a callback based API
 
 ## Deferred Dependencies
 
 Useful for optional dependencies which have a listener-style API, i.e. the dependent component registers a
-listener with the dependency and never calls it again(instead the dependency will call the registered listener).
-A good example is `Firestore`'s use of `Auth` where `Firestore` registers a token change listener to get
+listener with the dependency and never calls it again (instead the dependency will call the registered listener).
+A good example is `Firestore`'s use of `Auth`, where `Firestore` registers a token change listener to get
 notified when a new token is available. The problem is that when `Firestore` initializes, `Auth` may not be
 present in the app, and is instead part of a dynamic module that can be loaded at runtime on demand.
 
@@ -130,7 +129,7 @@ public interface Deferred<T> {
 }
 ```
 
-To use it a component needs to use `Dependency.deferred(SomeType.class)`:
+To use it a component needs to call `Dependency.deferred(SomeType.class)`:
 
 ```kotlin
 class MyComponent(deferred: Deferred<SomeType>) {