Merge pull request #4149 from ductnn/v1.13

Chore: Typo fixed in docs

daprdocs/content/en/operations/components/component-secrets.md

@@ -75,15 +75,14 @@ spec:
   type: bindings.azure.servicebusqueues
   version: v1
   metadata:
-  -name: connectionString
-   secretKeyRef:
+  - name: connectionString
+    secretKeyRef:
       name: asbNsConnString
       key: asbNsConnString
-  -name: queueName
-   value: servicec-inputq
+  - name: queueName
+    value: servicec-inputq
 auth:
   secretStore: <SECRET_STORE_NAME>
-
 ```
 The above "Secret is a string" case yaml tells Dapr to extract a connection string named `asbNsConnstring` from the defined `secretStore` and assign the value to the `connectionString` field in the component since there is no key embedded in the "secret" from the `secretStore` because it is a plain string. This requires the secret `name` and secret `key` to be identical.
 
@@ -95,7 +94,7 @@ The following example shows you how to create a Kubernetes secret to hold the co
 
 1. First, create the Kubernetes secret:
     ```bash
-     kubectl create secret generic eventhubs-secret --from-literal=connectionString=*********
+    kubectl create secret generic eventhubs-secret --from-literal=connectionString=*********
     ```
 
 2. Next, reference the secret in your binding:

daprdocs/content/en/operations/components/pluggable-components-registration.md

@@ -52,7 +52,7 @@ Since you are running Dapr in the same host as the component, verify that this f
 
 ### Component discovery and multiplexing
 
-A pluggable component accessible through a [Unix Domain Socket][UDS] (UDS) can host multiple distinct component APIs . During the components' initial discovery process, Dapr uses reflection to enumerate all the component APIs behind a UDS. The `my-component` pluggable component in the example above can contain both state store (`state`) and a pub/sub (`pubsub`) component APIs.
+A pluggable component accessible through a [Unix Domain Socket][UDS] (UDS) can host multiple distinct component APIs. During the components' initial discovery process, Dapr uses reflection to enumerate all the component APIs behind a UDS. The `my-component` pluggable component in the example above can contain both state store (`state`) and a pub/sub (`pubsub`) component APIs.
 
 Typically, a pluggable component implements a single component API for packaging and deployment. However, at the expense of increasing its dependencies and broadening its security attack surface, a pluggable component can have multiple component APIs implemented. This could be done to ease the deployment and monitoring burden. Best practice for isolation, fault tolerance, and security is a single component API implementation for each pluggable component.