Search UI

[alfredgrip]

This PR rewrites search in frontend so that it uses the Meilisearch endpoint introduced in #611

It also adds a "advanced search" that allows filtering search on different indexes

It also fixes some minor TS misses that slipped through in the #611 PR

To try out this PR, please ensure that Meilisearch is up and running on your Docker (rerun the dev/setup_db.sh script) and then head to localhost:.../admin/debug and press Sync with Meilisearch

[Isak-Kallini]

Search in english doesn't seem to be working, for example:
The bottom article comes up when searching for test

But when searching for its title it doesn't show up:

This is with language set to english, the article also comes up if i search for it's swedish title

Also if I press backspace while the input is empty the spinner appears until I type something

But looks great overall, feels very nice to use. Big improvement compared to before!

[alfredgrip]

Search in english doesn't seem to be working

I found the issue for this. The /search page does a fetch to the api endpoint (which in turn makes a request to Meilisearch). When the server on the search page gets a request, the event.locals.language gets populated to the correct value by hooks.server.ts. But when the /search does a fetch to the API endpoint, the server there checks for event.locals.language but it defaults to swedish.
Tried some console logging and found this when trying to search with language set to en:

search param language is: en      // query parameter
search locals language is: en     // event.locals.language
API param language is: en         // query parameter
API locals language is: sv        // event.locals.language

So either the hooks.server.ts is faulty, or the /search server needs to do the fetch some other way. When the API page instead gets language from the query parameter, search in english works as intended.

@danieladugyan Do you have any thoughts about this?

[alfredgrip]

I found the issue for this. The /search page does a fetch to the api endpoint (which in turn makes a request to Meilisearch). When the server on the search page gets a request, the event.locals.language gets populated to the correct value by hooks.server.ts. But when the /search does a fetch to the API endpoint, the server there checks for event.locals.language but it defaults to swedish. Tried some console logging and found this when trying to search with language set to en:

search param language is: en      // query parameter
search locals language is: en     // event.locals.language
API param language is: en         // query parameter
API locals language is: sv        // event.locals.language

So either the hooks.server.ts is faulty, or the /search server needs to do the fetch some other way. When the API page instead gets language from the query parameter, search in english works as intended.

I found that this can simply be fixed if the /search server does a request to /en/api/search if locals.language == "en". I'm not a big fan of this, however. Having two "different" API endpoints that does the same, but which could easily be merged in to a single one by having a query parameter i.e. ?language="en", seems weird. I think it makes more sense to have a single one that accepts the language query parameter. What are your thoughts @Isak-Kallini @danieladugyan ?

E.g. I don't like the look of this:

let url;
if (event.locals.language === "sv") {
  url = new URL("/api/search", event.request.url);
} else {
  url = new URL("/en/api/search", event.request.url);
}

[danieladugyan]

I found that this can simply be fixed if the /search server does a request to /en/api/search if locals.language == "en". I'm not a big fan of this, however. Having two "different" API endpoints that does the same, but which could easily be merged in to a single one by having a query parameter i.e. ?language="en", seems weird. I think it makes more sense to have a single one that accepts the language query parameter. What are your thoughts @Isak-Kallini @danieladugyan ?

Sorry, that's my bad for introducing the bug. Anyways, that's exactly how I think it should work. It's consistent with how language is handled everywhere else in the app.

1. The request hits the server.
2. paraglide.js looks at the URL and check if it has a language prefix, i.e /en, and sets the language in event.locals accordingly.
3. Route handlers use event.locals.language as needed - the Prisma translationExtension doing this automatically is enough in most cases.

In summary, if we're on the Swedish site, fetch normally, otherwise fetch with 'en' prepended. Ideally this would be done automatically by the library, but maybe we could make a fetch wrapper?

[alfredgrip]

I think it's weird though, specifics sent to an API endpoint should IMO be in the query parameters, not extracted from the URL. But I guess this works.

Just pushed some changes that fixes the english search and also handle translation mapping.

but maybe we could make a fetch wrapper?

So we would write a wrapper for the already existing event.fetch wrapper from SvelteKit? 🫠

[Isak-Kallini]

I think that solution looks fine since, as Daniel says, that's how language is handled everywhere else.
But should maybe use i18n.resolveRoute('/api/search')?

[alfredgrip]

I think that solution looks fine since, as Daniel says, that's how language is handled everywhere else. But should maybe use i18n.resolveRoute('/api/search')?

Didn't know that was a thing, but that's a nice way to handle it I guess!

[Isak-Kallini]

One small comments, looks good otherwise.
Great job!

[Isak-Kallini]

form.message looks nicer?