Apply suggestions from code review

Co-authored-by: Stacey Gammon <gammon@elastic.co>

Author: ppisljar

dev_docs/key_concepts/persistable_state.mdx

@@ -7,22 +7,22 @@ date: 2021-02-02
 tags: ['kibana','dev', 'contributor', 'api docs']
 ---
 
- “Persistable state” is developer-defined state that supports being persisted by a plugin other than the one defining it. Persistable State needs to be serializable and the owner can/should provide utilities to migrate it, extract and inject references from/to it, as well as telemetry collection utilities.
+ “Persistable state” is developer-defined state that supports being persisted by a plugin other than the one defining it. Persistable State needs to be serializable and the owner can/should provide utilities to migrate it, extract and inject any <DocLink id="kibDevDocsSavedObjectsIntro" section="references" text="references to Saved Objects"/> it may contain, as well as telemetry collection utilities.
 
 ## Exposing state that can be persisted
 
-Any plugin that exposes state that another plugin might persist should implement `PersistableStateService` interface on their `setup` contract. This will allow plugins persisting the state to easily access migrations and other utilities.
+Any plugin that exposes state that another plugin might persist should implement <DocLink id="kibKibanaUtilsPluginApi " section="def-common.PersistableStateService" text="`PersistableStateService`"/> interface on their `setup` contract. This will allow plugins persisting the state to easily access migrations and other utilities.
 
 Example: Data plugin allows you to generate filters. Those filters can be persisted by applications in their saved 
-objects or in the URL. In order to allow apps to migrate the filters in case the structure changes in the future, the Data plugin implements `PersistableStateService` on `data.query.filterManager`.
+objects or in the URL. In order to allow apps to migrate the filters in case the structure changes in the future, the Data plugin implements `PersistableStateService` on <DocLink id="kibDataQueryPluginApi " section="def-public.FilterManager" text="`data.query.filterManager`"/>.
 
 note: There is currently no obvious way for a plugin to know which state is safe to persist. The developer must manually look for a matching `PersistableStateService`, or ad-hoc provided migration utilities (as is the case with Rule Type Parameters).
 In the future, we hope to make it easier for producers of state to understand when they need to write a migration with changes, and also make it easier for consumers of such state, to understand whether it is safe to persist.
 
 ## Exposing state that can be persisted but is not owned by plugin exposing it (registry)
 
 Any plugin that owns collection of items (registry) whose state/configuration can be persisted should implement `PersistableStateService`
-interface on their `setup` contract and each item in the collection should implement `PersistableStateDefinition` interface.
+interface on their `setup` contract and each item in the collection should implement <DocLink id="kibKibanaUtilsPluginApi" section="def-common.PersistableStateDefinition" text="`PersistableStateDefinition`"/> interface.
 
 Example: Embeddable plugin owns the registry of embeddable factories to which other plugins can register new embeddable factories. Dashboard plugin
 stores a bunch of embeddable panels input in its saved object and URL. Embeddable plugin setup contract implements `PersistableStateService`
@@ -40,7 +40,7 @@ export interface EmbeddableRegistryDefinition extends PersistableStateDefinition
 export interface EmbeddableSetup extends PersistableStateService<EmbeddableInput>;
 ```
 
-note: if your plugin doesn't expose the state (is the only one storing state) plugin doesn't need to implement `PersistableStateService` interface.
+Note: if your plugin doesn't expose the state (it is the only one storing state), the plugin doesn't need to implement the `PersistableStateService` interface.
 If the state your plugin is storing can be provided by other plugins (your plugin owns a registry) items in that registry still need to implement `PersistableStateDefinition` interface.
 
 ## Storing persistable state as part of saved object
@@ -62,7 +62,7 @@ note: Currently there is no recommended way on how to store version in url and i
 ### Extraction/Injection of References
 
 In order to support import and export, and space-sharing capabilities, Saved Objects need to explicitly list any references they contain to other Saved Objects.
-To support persisting your state in saved objects owned by another plugin, the `extract` and `inject` methods of Persistable State interface should be implemented.
+To support persisting your state in saved objects owned by another plugin, the <DocLink id="kibKibanaUtilsPluginApi" section="def-common.PersistableState.extract" text="`extract`"/> and <DocLink id="kibKibanaUtilsPluginApi" section="def-common.PersistableState.inject" text="`inject`"/> methods of Persistable State interface should be implemented.
 
 <DocLink id="kibDevTutorialSavedObject" section="references" text="Learn how to define Saved Object references"/>
 
@@ -80,4 +80,4 @@ As your plugin evolves, you may need to change your state in a breaking way. If
 
 ## Telemetry
 
-You might want to collect state about how your state is used. If that is the case you should implement the telemetry method of Persistable State interface.
+You might want to collect statistics about how your state is used. If that is the case you should implement the telemetry method of Persistable State interface. 

examples/embeddable_examples/server/searchable_list_saved_object.ts

@@ -31,7 +31,7 @@ export const searchableListSavedObject = (embeddable: EmbeddableSetup) => {
       },
     },
     migrations: () => {
-      // there are no migrations defined for the saved object at the moment, possibly they wuuld be added in the future
+      // there are no migrations defined for the saved object at the moment, possibly they would be added in the future
       const searchableListSavedObjectMigrations = {};
 
       // we don't know if embeddables have any migrations defined so we need to fetch them and map the received functions so we pass