Trigger search addon from flyout input

[humitos]

This is an initial attempt to be able to render the readthedocs-search addon inside the readthedocs-flyout one.

I was able to:

• include the readthedocs-search tag inside the flyout
• connect the focusin event to the input from inside the flyout to call the search

Each time I click on the input from inside the flyout, it shows a log in the console (for debugging). However, due to some reason that I don't know yet, the readthedocs-search tag does not contains any HTML inside ito, so even when the modal is triggered, nothing is shown.

Related #90

[humitos]

I was able to make this work with a simpler approach. However, I would need some feedback here and maybe some javascript guidances since there some things that can be improved.

I want to read more documentation and play a little more with this pattern, but it seems it's the way to go.

Working example

[agjohnson]

Before we invest too heavily into using shadow DOM internals, I feel there are some easier solutions here that we can explore first:

Is there a reason we need to nest the web components in the first place? The search input is a modal that is separate from the flyout, and that users can implement in a doc native search input element. The flyout only requires a method to make the search modal visible.

If there is not a strong reason for this nesting, we only need a pattern for making the search web component modal visible from an element in the flyout web component.

The path forward I'm describing is:

• Search web component handles a custom DOM event, for example the Lit docs on handling an event from another web component shows how custom events work between two web components.
• The flyout UI element to trigger search would fire this event off, ie @focus="${this.showSearch}"

This should remove the need for nesting, but also only requires that the search web component be defined once, globally, on the page.

[humitos]

This feedback is great, thanks! I will read a little more and explore your ideas.

[humitos]

Is there a reason we need to nest the web components in the first place? The search input is a modal that is separate from the flyout, and that users can implement in a doc native search input element. The flyout only requires a method to make the search modal visible.

Exactly. Originally, I tried to connect the input from inside the flyout to trigger the modal, but I wasn't able to. However, while I was doing the research to nest the search, I found how to connect the event with the input from inside the flyout -- but at that time I forgot that original idea 😅

However, I think this research will be useful for addons like docdiff (or similar ones) that has a UI (small checkbox for the docdiff currently). So, I guess that at some point we will need to nest them, maybe?

The path forward I'm describing is:

I will check this path 🚀

[agjohnson]

So, I guess that at some point we will need to nest them, maybe?

Good question. Yeah, especially for docdiff that is still unknown. The docdiff web component is a bit unique, in that it has two components really -- the UI slider and the actual DOM manipulation part. I could see authors wanting to customize both, maybe independently even?

[humitos]

Man, I implemented your idea and it was pretty simple 🚀 . I think this is ready to get merged.

[agjohnson]

💪 This is great! I'm glad this option worked out well for us, hopefully this pattern can work for docdiff and the flyout menu too.

[agjohnson]

I could see us wanting to reuse this pattern a number of times perhaps. Maybe it makes sense to have event names defined as constants in a separate, events.js import?

[humitos]

I moved this to an event.js file and import the event from the addons.