🚧 Search implementation

[bldng]

I have started with a basic search implementation. Currently it is only possible to filter pages, but I also had in mind to have more global search. This would require parsing the page contents (search already returns a Promise) but also a different element as it would allow jumping to anchors etc.

To discuss: Setting optional keywords in the catalog config to manually define groups:

{
  path: 'button',
  title: 'Button component',
  component: require('...'),
  keywords: ['UI', 'controls']
}

Roadmap

• [x] Filter pages (basic search)
• [ ] Finalize styling
• [ ] Parse page content (return anchors for headings / specimens)
• [ ] Check performance for full indexing (web-worker? cache index?)

[jstcki]

As promised, here are my thoughts. Nothing conclusive but I see several challenges with implementing search well:

Modularity

Generally, I'd prefer an approach where we don't couple Catalog too closely to a particular implementation. I think it would be valuable to offer a built-in solution but it has to be lightweight and more importantly replaceable by the user, e.g. by an Algolia search. So we should focus primarily on providing the necessary hooks to make that happen and then building the built-in solution on top of those hooks.

Indexing

I'm pretty convinced that indexing in the browser is a bad idea, even when done in the background in a ServiceWorker. It would require to load all the content to create an index and disable the search while doing so.

Creating an index when running catalog build (or as a separate command) seems like the sensible thing to do but would require parsing of the content with something like #307 (but not exclusively).

In any case we have to deal with the fact that we don't just have Markdown files to index but also content in JS files (either JSX or markdown template literal).

Another approach that could work if we had SSR would be to generate HTML pages first and then index those.

User Interface

Just filtering the navigation doesn't always make it obvious why something's matched, especially if we only show top-level page titles when matching sub-pages (or keywords!). Search results need to be contextualized, maybe in a panel (Algolia does this pretty well IMHO)?

[plaetzchen79]

I would really appreciate such a basic search function. I hope this feature will make it.

[leog]

Very good points @herrstucki. I guess that going the extra mile on having a convincing search tool goes against the concept of having a flexible and replaceable search tool, so maybe we (I want to help!) can pinpoint where to draw the line and go from there.

BTW, I didn't know about Algolia, neat service! I was going to suggest something like Bootstrap provides but *surprise* they use Algolia 😄 I see they have a "Community" tier (I love when companies support open source), but going that way would be tieing Catalog to their service, so I guess the implementation should support the external decision about using it but I don't think it should come out-of-the-box.

Anyway, my feeling is that, as Catalog could be used for such a variety of projects, and Catalog by itself can't really infer the type of content beforehand; the searchable content, its context and its UI should be defined in an abstract way, so the implementation can tackle the searchability of that abstract concept, and then open up the possibility that people could hook up their own specific search abilities dependning on their requirements. Otherwise the search solution will never be good enough as the types of content will never cease to change with time.

[fc-janharold]

Would love to have this as well.

[westin]

Any progress on this? Would love a plug-and-play search experience.