diff --git a/examples/embeddable_examples/public/searchable_list_container/searchable_list_container_component.tsx b/examples/embeddable_examples/public/searchable_list_container/searchable_list_container_component.tsx
index c24d258fd7d8..7e742aba7cc7 100644
--- a/examples/embeddable_examples/public/searchable_list_container/searchable_list_container_component.tsx
+++ b/examples/embeddable_examples/public/searchable_list_container/searchable_list_container_component.tsx
@@ -82,7 +82,6 @@ export class SearchableListContainerComponentInner extends Component
+ 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'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. +
Check out the "Dynamically adding children" section, to see how to add diff --git a/src/plugins/embeddable/docs/input_and_output_state.md b/src/plugins/embeddable/docs/input_and_output_state.md index 2fd8799099b6..a0cd4cc5c0ef 100644 --- a/src/plugins/embeddable/docs/input_and_output_state.md +++ b/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! \ No newline at end of file