Implement offline search API

[rapee]

We want to search across dataset (people / zipcode / party / vote logs). Can we do offline e.g. not loading external API?

const results = searchByKeyword("ประชา")

Response body:

#11 (comment)

[p16i]

One way might be to let use which attribute to search and we load an index file accordingly.

[rapee]

You mean to choose attribute first, then search the correct index file? @heytitle

[p16i]

Yes. We can also create a combined index file, but i'm not sure how hard it is to construct such a file.

[rapee]

One idea is to create simple lookup index like this for all content types that are of our concerns.

[
  { q: "สว", type: "page", url: "/cabinet" },
  { q: "พลเอก ประยุทธ์ จันทร์โอชา", type: "people", url: "/people/ประยุทธ์-จันทร์โอชา" },
  { q: "เพื่อไทย", type: "party", url: "/party/เพื่อไทย" },
  { q: "ขยายสัญญาสัมปทานทางด่วนและรถไฟฟ้าบีทีเอส", type: "votelog", url: "/votelog/3" },
  // ... go on
]

Then, partial matching of q with search keyword should give a simple yet just-work search function.

[rapee]

For word variations like "สว", we could do RegExp:

[
  { q: "ส\.?ว.\?", match: "regexp", type: "page", url: "/cabinet" },
  // ... go on
]

[Th1nkK1D]

@rapee let see if I understand correctly

1. Generate "look up index" from the data we have. Might be array of object like your previous comment.
2. Create function searchByKeyword to filter data in index file using regex.

[rapee]

That’s right @Th1nkK1D

[p16i]

imho, we also have to check the size of the index file. If it shouldn't be too large. @rapee any idea about the reasonable file size?

Given that this index file doesn't change regularly, we might cache it using local storage.

In term of indexing, we might need to construct a search tree somehow for efficient look-ups. I'm not sure whether huffman encoding is suitable here.

[Th1nkK1D]

Idea proposed with prototype v1 implemented in PR #156
Feel free to discuss :)

[rapee]

I think it's best to not exceed 500 KB. Storing on local storage is good idea.

I haven't done benchmark search performance yet, but given the current number of indexed records are within 1,000, it might not be top priority. I think we implement the first version of search component first, then we can try exploring huffman and other ideas.