Skip to content

Commit

Permalink
Fix some wording in the embeddable readme
Browse files Browse the repository at this point in the history
Signed-off-by: abbyhu2000 <abigailhu2000@gmail.com>
  • Loading branch information
abbyhu2000 committed Apr 21, 2023
1 parent 839c38e commit 185b680
Showing 1 changed file with 1 addition and 4 deletions.
5 changes: 1 addition & 4 deletions src/plugins/embeddable/docs/input_and_output_state.md
Original file line number Diff line number Diff line change
Expand Up @@ -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!

0 comments on commit 185b680

Please sign in to comment.