cc @streamich -- am adding this helper react class. All my examples ended up with the same subscription code, etc. Lmk if you have any suggestions.

This withEmbeddableSubscription higher order component seems to be OK. I'm planning to improve Embeddable DX in general for React, so you would not need to write such helpers.

Will this import work once #52447 is merged?

yea, there is a /* eslint-disable */ surrounding it (as there was originally). The example plugins actually make this easier because they can export the examples at the top level, while we don't want that in here. I've thought about replacing all these samples with ones from the examples repo but some really are only built for testing not so much examples. Some of this could still probably be cleaned up and more example embeddables used for testing.

Why would you register some in the setup phase and dome in the start?

I assume they internally consume services available only in the start phase, but how can we make this clearer to devs (including ourselves)?

Yep, because deps.embeddable.getEmbeddableFactory is only available in start, not setup. :( I could move them all to start... or make getEmbeddableFactory available in both. I'm not sure what the best thing is, I think this whole when to expose a registry getter we still don't have a super clear recommendation of. Unless we do and I am just not caught up yet. For now I'll add a comment.

I find the fact that filter applies only to inner items to be confusing
If you could hide empty items or gray them out, it would be much clearer.

Yea, I agree, but I wanted an example of a container passing data down to the child. I agree the scenario you mention would make more sense but we'd need them to implement something so the child could communicate "i have a match vs no match" to it's parent and we don't have that kind of communication yet.

Think of it like on the dashboard - we pass down the filters and the child does something with that, but the container never changes how the child is rendered.

It is something to think about though. I wonder if there is a better example I could do here. Maybe pass down "highlight" and highlight the search terms instead of filter by them? What do you think?

Actually that's a great idea - search highlight would make it much clearer

Couldn't EmbeddableFactoryRenderer and EmbeddableRoot be the same component?
It feels like they couldn't really exist one without the other, or could they?

EmbeddableFactoryRenderer encapsulates more logic, but EmbeddableRoot is helpful if you need a reference to the embeddable object, like in todo_embeddable_example. Adding some text there:

                You may also notice this example uses `EmbeddableRoot` instead of the
                `EmbeddableFactoryRenderer` helper component. This is because it needs a reference
                to the embeddable to update it, and `EmbeddableFactoryRenderer` creates and holds
                the embeddable instance internally.

If it's a TODO app, I would expect to be able to add new items.
I could't figure out how to add a new item, just edit the existing one?

Not yet, but it's a good idea to add and I might be able to showcase the add panel flyout. Just felt like this PR was getting big so wanted to stop. There are def more examples of use cases I'd like to add.