x-topic-search and x-interaction challenges

[dan-searle]

In order for x-topic-search's results to be closed when you interact with something else on the page, we need do something like this:

['focusout', 'focusin', 'click'].forEach(action => {
	document.body.addEventListener(action, event => {
		if(!componentRootNode.contains(event.target)) {
			topicSearchActions.hideResult();
		}
	});
});

(We can't just listen for the blur of the topic search input, as this will cause the search results to close when you click inside the search results (e.g. on the follow button).)

So, there's a couple of questions:

1. What is an acceptable way for an x-dash component to add (and remove) DOM event listeners outside of themselves? (we should avoid it if we can, but in this case it seems unavoidable).
2. How to pass a ref to a DOM node from the wrapped component to the action? E.g. the event handler has this condition: componentRootNode.contains(event.target)

[i-like-robots]

So I'll speak for FT.com... I think it's fine to use regular class components, add these listeners when the component is mounted, and remove them when unmounted. I'm sure this is not new advice to you but I guess this is the happy path. #248 indicates this may also be the way forward.

I can't offer any insight as to whether this approach would or would not work in the app.

[apaleslimghost]

that approach is fine for the app, but not exposing class components means we have much more control over statically verifying that components aren't doing bad things