Enable single search over all categories/content

[bluepuma77]

As I developer I am mostly interested in solving my challenges with Svelte(Kit). Be it building a SvelteKit Docker container or understanding how to deal with mongoose database initialisation or animated modal dialogs. I do not care if a solution is considered to be a "template", a "component", "tools" or "recipes".

Currently I need to use multiple searches to check if anything relevant is present on sveltesociety.dev. That is not very convenient and makes the site for me not an automatic go-to-place for things Svelte(Kit) related.

Therefore it would be great to get a single search over all categories on sveltesociety.dev. Just a simple Google-like keyword search over all content. Hopefully with a search box directly on the front-page.

[nvlgzr]

I started looking at this today as it seems like a fairly obvious win. For the most part, it seems like there's nothing too technically challenging here, but I suspect more discussion's needed first: there's more than one way to skin this cat (oops…sorry, PETA!), so it's not clear to this new contributor how best to proceed.

That said, I've captured some thoughts from my research in order to spur some discussion and/or provide guide posts for whoever ends up doing the implementation.

Research results

Data Sources

Recipes is the odd one out, with metadata loaded from .svx files in src/routes/recipes/*/**. It lack most of the fields present in the other three.

Data for the Template, Component, and Tool "types" are stored in eponymous JSON files:

[src/routes/]
├── templates
│   ├── index.svelte
│   └── templates.json
├── templates
│   ├── index.svelte
│   └── templates.json
└── tools
    ├── index.svelte
    └── tools.json

I'm unsure not sure where these came from…maybe they're manual exports from a GitHub query? At any rate, it's useful to see that they all share a common type, which I'll call Repo for the purposes of this discussion:

type Repo = {
  title: string;
  description: string;
  url: string;
  category: string;
  addedOn: Date;
  stars: number;
  tags?: string[];
}

There's also an extra property — npm — present in only one type: components.json. It could be thought of as another optional property on that ↑ Repo type, or it could be handled as a sub-type, e.g.,

type Component extends Repo {
  type: "component";
  npm: string;
}

Broadly speaking, we've identified 2 datatypes: Recipes (typed here) & Repos.

For completeness, I invite you to consider a 3rd datasource for this feature: the entire site's page content! Just sayin'.

Views / UX

This is where I hope someone who's been working on the project can chime in a bit, because the realm of design is one of infinite possibility…also known as "options paralysis".

• Where does search on the home page go?
• Should it be accessible via keyboard shortcut (e.g., the way typing / in most Google products gives focus to the search bar?
• If the unified search is good enough, is there any point in retaining the 3 headers: Templates | Components | Tools?
  • If so, how can the base model be made implicitly clear in the UX so that the addition of a unified search field doesn't make the experience worse?
  • If not, how will the design need to change in their absence?
• Should the unified search be universally accessible (i.e., in the top nav), or, like the other searches, limited to the root route?
  • If search is to be persistent in the global nav, will it feel even weirder than now when recipes, cheat sheet content, and events fail to appear in search results?
  • Otherwise…well, actually, I think there's a "right" answer here, and it's "Put Search in the nav!" I can't personally think of a reason not to.

There's plenty of room for incrementalism here, and I'd be happy to help move this forward in movable baby steps, so long as others can provide some direction.