It's another iteration of this kind of blogpost (also because I can't sleep, so I'll give another shot on writing blogpost).

In previous post, I've added simple tagging system. Nothing big. Just adding new field, then create page for searching a particular tag. I even haven't make it able to search multiple tags. Probably will go for another iteration.

But the most "disgusting" part of it is the tagging system. It just a plain text field, where the tags are separated by a space. It... sucks.

And so be it. An attempt on improving the tagging system while thinking about efficiency.

Initial : Manual Search

As my posts are made up from mongoDb documents, adding a field to the schema is fairly easy. Because a post can contain many tags, then I made it into array. And this is where things going a little bit complicated.

Searching using mongoDb can be as simple as using find() method and let the driver do the job. Lets say you want to search for posts that contain tag "coding", then the code will go like

const posts = await Post.find({ tags: "coding" });

That is for a single item inside an array. Multiple tags need another approach, but that's out of this post's scope.

Lets say that you want to search for tags with similarity to what you've already written. Think it as the autosuggestions given by Google Search when you barely finish any phrases or complete your words. The simple, yet effective approach is to use regex. It can go like this, with example of searching posts with title having "an" as substring

const regex = new RegExp("an");
const posts = await Post.find({ title: { $regex: regex } });

And voila, you got list of posts that matches your search.

But here we're talking about retrieving tags that already exists (used by other posts), and getting the total amount of usage for each tag. The manual search gonna cost a lot, because you'll go into routines of fetching all posts, getting the tags array, then check if any tag inside has some similarity with the search string, then count them, yada yada yada... Too complicated.

That's why we'll go with another approach

Statistics Model Approach

This is just how I name my stuffs. I don't know if there is any official name, so let me know if there is any.

The closest term that can be used is "Materialized View", which is to create a "view" that serve particular purposes. Think the "view" as a table that summarizes stuff. Neat stuff.

So, I created another model, lets name it "Tags". The attributes for this model are :

"name" : The name of the tag. String
"count" : The count or total usage of the tag. Number
"posts" : Array of ObjectId pointing to posts that use this tag

For the bare minimum, only "name" and "count" field required. The "posts" field is for another purpose (which I haven't thought on, ehe).

We will only use this model as the data source for getting the tags with the statistics. And because the "name" is a field with string data type, it's fairly easy to use the regex search like in the example before.

async function getSimilarTags(searchString: string) {
    const tags = await Tag.find({ name : { $regex : new RegExp(searchString) } });
    return tags;
}

Above is example for querying the tags. Now we can use the result provided to build the tag autosuggestion system. No need to worry about the amount of result because we can simply use the "count" field.

Autosuggestion

As I'm a pretty lazy person, I always search for already existing components which I can play with. I'm already using Material UI for building the UI for the blog editor, so you know my direction.

I'm using Autocomplete component from Material UI Lab, which already giving me bare stuffs I need to build my tag autosuggestion component.

The difference lies on the changing options with respect of response of API call. So another handler was made for API call, and the response is saved as state (using useState). This state is used by Autocomplete component as the source of options. The rest are just handling the behavior of the component, as well as the rendering of the options. There need some tweaking when searching for non-existing tags, which means that there will be new tag added. But in the end, it's mostly exploring the API given by the component. Below is the result.

Looking on how many stuffs I dealt with this component, the detailed explanation on using Autocomplete component will go on the next post. It's now up to whether I remember to write it ehe.

But for now, I'm pretty happy with the result. API call now is efficient as there no need to waste lots of API call as I've explained before.

There is another drawback tho. For each CRUD operations on the post, especially those that affects the tags, the documents in Tags model needs to be kept consistent, so each addition/removal of tags from a post needs to be handled, as well as creation/deletion of posts. Things are going for several extra steps if "posts" field is exist.

Conclusion

Tag autosuggestion is a nice feature to have, especially when having such a broad tags available. You just want to make sure you're using the right tag, with high number of result to ensure your stuff is in the crowdy place of the site.

And I think that's it. See ya

Log-0x11 - Advanced Tag Suggestion Autocompletion