Fix wording and duplicate code in embeddable example plugin (opensear…

…ch-project#3911)

* Fix wording and duplicate code in embeddable example plugin

Signed-off-by: abbyhu2000 <abigailhu2000@gmail.com>

* Fix some wording in the embeddable readme

Signed-off-by: abbyhu2000 <abigailhu2000@gmail.com>

---------

Signed-off-by: abbyhu2000 <abigailhu2000@gmail.com>

examples/embeddable_examples/public/searchable_list_container/searchable_list_container_component.tsx

@@ -82,7 +82,6 @@ export class SearchableListContainerComponentInner extends Component<Props, Stat
       const output = props.embeddable.getChild(id).getOutput();
       hasMatch[id] = hasHasMatchOutput(output) && output.hasMatch;
     });
-    props.embeddable.getChildIds().forEach((id) => (checked[id] = false));
     this.state = {
       checked,
       hasMatch,

examples/embeddable_explorer/public/list_container_example.tsx

@@ -164,6 +164,15 @@ export function ListContainerExample({
               The first HelloWorldEmbeddable does not emit the hasMatch output variable, so the
               container chooses to hide it.
             </p>
+            <p>
+              Type some strings in the search bar, and press Check matching button. If the search
+              string matches with any strings from the title or the description of the children
+              embeddables, the child embeddable&#39;s check box will be checked. Noted that the
+              search filter is case sensitive. However, even if the search string matches with the
+              strings in the HelloWorldEmbeddable, its check box will not be checked because of the
+              reason explained above. If we click Delete checked, all the selected child embeddables
+              will be deleted from the container.
+            </p>
 
             <p>
               Check out the &quot;Dynamically adding children&quot; section, to see how to add

src/plugins/embeddable/docs/input_and_output_state.md

@@ -274,9 +274,6 @@ There are no real life examples showcasing this, it may not even be really neede
 the thinking being that it would support any type of rendering of child embeddables - whether in a "snap to grid" style like dashboard,
 or in a free form layout like canvas.
 
-The only real implementation of a container in production code at the time this is written is Dashboard however, with no plans to migrate
-Canvas over to use it (this was the original impetus for an abstraction). The container code is quite complicated with child management, 
-so it makes creating a new container very easy, as you can see in the developer examples of containers. But, it's possible this layer was
- an over abstraction without a real prod use case (I can say that because I wrote it, I'm only insulting myself!) :).
+The only real implementation of a container in production code at the time is written in the Dashboard plugin, however, with no plans to migrate over to Canvas (this was the original impetus for an abstraction). The container code is quite complicated with child management, so it makes creating a new container very easy, as you can see in the developer examples of containers. But, it's possible this layer was an over abstraction without a real prod use case (I can say that because I wrote it, I'm only insulting myself!) :).
 
 Be sure to read [Common mistakes with embeddable containers and inherited input state](./containers_and_inherited_state.md) next!