Docs search

[joeyballentine]

Minisearch is great

[RunDevelopment]

I think the layout is a bit confusing. Without using it, it's not clear that the search box only filters the entries in the nodes list. There's just no visual connection between the two.

Maybe we could put it above the nodes list? This would make the connection very clear. The node selector already uses this layout, so users should be able to immediately know what it does.
The only inconsistency between the two would be that the node selector uses a different search algorithm and will return different results. This might not be an issue though.

[joeyballentine]

[RunDevelopment]

This is what gets logged when I open docs for the first time.

[RunDevelopment]

I think we should include input/output descriptions+names in the search. It's confusing that they aren't included.

[joeyballentine]

This is what gets logged when I open docs for the first time.

I think this was fixed in one of my other PRs. Could you check again? @RunDevelopment

Actually I think it's fixed in #1929 so just wait for that to me merged. It's something I had overlooked in one of the PRs I merged last week and isn't caused by this I think

[RunDevelopment]

I'm mean, I know.

I'm honestly not sure what the best way of fixing this is, but I can think of 2 approaches:

1. We go in deep on describing the page. Basically, we create an intermediate representation (IR) for the docs of a single node. This IR would already have most extra infos (e.g. supported file types, etc) rendered as text. Search would then be done on the IR. Rendering the IR should be fairly simple.

   However, this does mean that it will be harder to add features to the docs, since we have to funnel everything through the IR first. So something like "add a button here" would be very difficult.

2. We abuse React. We'll use React to (1) create the rendered pages of all nodes, (2) extract their text, and then (3) search on the extracted text. Step (1) and (3) are easy. Step (2) is the issue. We need a way to only extract the text that we are interested in. Just taking all text might be an okay approximation, or we might need something smarter. (Step 1 and 2 are cached btw.)

   The main advantage of this approach is that we don't have to worry about text search ever again, because it will search in everything. It will just work.

---

Anyway, do we want to do this now? If not, then feel free to merge. It's not prefect, but it's good enough as is.

[joeyballentine]

Yeah I don't really wanna worry about that right now. I don't think that's too big of a deal at the moment. We should definitely do something about it at some point but I think it's fine as-is for now