Improve searching on the site

[vhoyer]

Hello,

My suggestion is basically: "For each emoji, add a shortlist of "potential other related" gitmoji (e.g bug => hotfix)"

Was thinking about this in #405 and I quite like this idea, I will try find time to implement this, but if in the meanwhile anyone would like to do this, feel free.

[8xu]

Sounds good, to be honest! 😅

[vhoyer]

this is nice cuz it can help in the search function, but if @8xu wants to do that, I'd find it pleasing :D

[8xu]

this is nice cuz it can help in the search function, but if @8xu wants to do that, I'd find it pleasing :D

I pretty much have no idea of how can I implement that 😭

[vhoyer]

Oh, as a first thought, I'd probably create a json file in the data folder (mostly because I don't think this should be very useful information to the consumers of gitmoji.json), probably something like:

{
  relatedGitmojis: [
    // this is one group
    ['bug', 'ambulance', 'lock', 'rotating_light', 'green_heart', 'pencil2', 'adhesive_bandage', /* ... */],
    // this is another group
    ['recycle', 'art', 'zap', /* ... */],
    /* ... */
  ]
}

Ultimatly this PR would be mostly for we to agree about what emoji is related to what other :D

as a note, I think that there is no problem in an emoji be present in more than one group.

If you could do the first step in first organizing them, it would be awesome :D

[vhoyer]

If in the future we need to change implementation of this list, I don't think it should be a huge problem, that's why I don't think that we should focus much in the implementation details in this issue, and I think that the format of a PR is better to separate the emojis

[AntoineKM]

Or to avoid breaking changes, we could add a tags array on each emoji, so we could put them tags like "bug", "ci", "structure", etc.

[connorjs]

Tags are nice for the breaking change aspect, and handling the multiple categories case. I like that.

As for the categories, maybe we start with the default types in conventional commits?

fix, feat, BREAKING CHANGE (or !), build, chore, ci, docs, style, refactor, perf, and test

I know a few issues have touched on conventional commits in the past (issue search), so maybe this helps bridge that gap?

[vhoyer]

@connorjs if you could put the entire list together, I think it would be great, we can worry about the searching functionality on another PR also.

[cruzdanilo]

quoting my comment from #1310

another solution would be to add tags to the emojis so it's easier to search. in my experience, i find myself reading the whole list of emojis far too many times because the search is inefficient. there is a silver lining to this process, that i got familiarized with the whole set of gitmojis, but it's not easy for newcomers. for example, if someone searches for "image" or "audio", they won't find any result, when they should find 🍱 (assets). if they search for "sound", it's even worse, they will find 🔊 (logs) because its code is loud_sound. the tags could also direct developers to more accurate emojis, for example, if someone searches for "readability" the result could be 🎨 (improve structure/format), avoiding the generic ♻️ (refactor).

in my opinion, the tagging feature should be search-oriented and include many keywords per emoji, with a focus on clearly guiding the searcher instead of giving too many options.

[carloscuesta]

Hey!

I believe we have a lot of potentials things that we can improve, but I'm not sure if it makes sense to put everything on the JSON file as it can become quite hard to maintain.

I'm thinking about introducing a CMS for this so we can manage the content easily without having to deploy or change anything, just pulling the content from an external service and incrementally regenerate the site as changes happen

https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration#on-demand-revalidation

The issue I see with this approach is that we would "loose" the collaboration aspect on the project, as far as I know I'm not aware of any "Open Source" CMS that somehow integrates with a repo.

This would allow us to move without having to rely on the gitmojis package for the rendering of the website.

[vhoyer]

I mean, I don't know why we would like to disassociate the website from the gitmojis package, but regarding the CMS, we might want to take a look at some git based CMS (like netlify-cms, which is only not a good suggestion because it doesn't receives any update since like, two years or so). That way we can either use the CMS to edit, or edit the files directly on the repository.

Regarding the feature "related search", we could use into https://github.com/oramasearch/orama it's a search engine written in typescript so it can be used in the browser, I've heard about it recently, but I've never tested.

[connorjs]

Re: Searching. I’ll check out orama (I’ve been wanting to check out the latest state of client side searching). I have also used https://github.com/gajus/liqe.

Re: CMS - I will defer to y’all on architecture decisions. I will take a pass on building out some tag taxonomy with a basic “define tags, and the tag defines its members” approach. (Although the alternative, gitmoji defines its tag, is just as valid.)

1. Conventional commit tags given its ease and existing issues
2. (second pass) Read through previous issues to define some other tags

[connorjs]

We could also make the existing semver field a tag (set of tags), or otherwise search by semver/display on website. (Probably a fast-follow/separate discussion though.)

[carloscuesta]

I mean, I don't know why we would like to disassociate the website from the gitmojis package,

In case we want to start adding tags, relationship with other emojis and potentially examples of usage and so on it can become quite painful to keep everything inside of a JSON file.

Also we should take into account that probably people that is consuming gitmojis as a dependency might not care about these attributes that we're adding just to improve the website, at the end of the day I see the gitmojis package as the source of truth for the convention, but external things that might compliment that list but are not necessarily the source of truth should be moved outside of that scope.

I'm sure we can improve the search system with a library to have better results but at the end of the day what we have right now is a shortcode, a unicode and a description for now.

Aside from improving the search we might want to explore improving the descriptions as well to make them more understandable?

[vhoyer]

Oh, in my original suggestion I was thinking of separating the related emojis into a different json file specifically because of that concern of yours of people consuming gitmojis package not being entirely interested in it.

But maybe some do, that's why I suggested adding a different json, so if people are interested in consuming it, it is available, if not, just don't import it, you know?

I was thinking, probably gitmoji-cli could benefit from including this related search logic into it as well.

[connorjs]

I was thinking, probably gitmoji-cli could benefit from including this related search logic into it as well.

Agreed. While I do not use the CLI, I assume it should offer similar features to the website. I also wondered if the CLI should live in the monorepo (maybe separate question; I'm looking deeply at the code for the first time).

FWIW, my first pass sketch built a separate JSON file (with JSON Schema), although I wonder if JS/TS-ifying it would be better given the lack of need for a literal JSON blob for tags IMO. Primary reason for JS (well, TS) would be enhanced auto complete of emoji names while writing tags (or vice versa).

[connorjs]

@carloscuesta or @vhoyer - What’s the best way to share my in-progress work when in a shareable state? Just submit a PR even with TODOs remaining?

[vhoyer]

Yes, I think a PR will do fine