feat: simple filtering / searching on bibliography

[CheariX]

This PR adds a simple filter/search functionality to the bibliography.

It can be used in two ways:

1. Simply enter a search term in the input box.
2. Send a search term via the location.hash, e.g., https://alshedivat.github.io/al-folio/publications/#mechanics

Notes:

• The search box is optional. It can be simply removed if anyone does not like it.
• Searching via hash works without the search box. My idea is to use this functionality to index all BibTeX entries via the ctrl-k search and link them via their BibTeX key.
• Searching via hash could also be used to set static links on the current page, e.g., to filter specific co-authors, venues, etc.
• I don't know much about the design of the input field. I simply reused the newsletter box style.
• Entering a search term in the box does exact matching. No fuzzy search, no AND/OR logic. I kept it very simple. Maybe anyone else wants to improve it in the future.
• The search looks in all data in the BibTeX entry that is parsed via bib.liquid. E.g., it is possible to search for BibTeX keys, titles, authors, years, venues, abstracts, or whatever bib.liquid prints.
• I used a 300ms delay before starting to search on the input box.
• Entering search terms in the box does not update the location hash (things could get complex otherwise due to automatically updating each other...)
• If the filter does not find any match in a specific year, the year is also made invisible.

Screenshot

Looking for feedback.

[george-gca]

I will try to test it this weekend. Question:

I used a 300ms delay before starting to search on the input box.

Why?

[george-gca]

It would be nice to highlight the search term found, so it would be clear why that item was selected. Something like the current search does:

[CheariX]

I will try to test it this weekend. Question:

I used a 300ms delay before starting to search on the input box.

Why?

In contrast to the Ctrl-k search, this one is a bit "hacky". It operates on the HTML DOM rather than on a pretty JSON structure. I was a bit scared that the search could slow down the browser while typing. Waiting 300ms before starting to search reduces unnecessary workload. Without that, the search would be triggered with every key up while typing the search term. E.g, typing "mechan" would trigger the filtering 6 times. With normal typing speed below 300ms, only one filtering is triggered.

300ms seems to be fast enough for me to not get bored. I do not even feel this delay.

I'm open to change this if anyone thinks it is unnecessary.

It would be nice to highlight the search term found, so it would be clear why that item was selected. Something like the current search does:

This is something that I would also like to have.

Unfortunately, I have no idea how to do this. Help is appreciated here. Or we leave it for a future PR.

Also, the filter currently searches in "hidden" texts like abstract or bibtex. Should they be opened automatically?

[CheariX]

I found a very cool library that was easy to integrate and does exactly what we are looking for (ref: highlight-search-term).

Pro:

• Easy integration
• Does not use any clunky <mark> or <span> elements for highlighting => Does not pollute the DOM.

Con:

• One more library/dependency. Do we want that?
• I think the integration could be improved. My code works, but could be improved. E.g., I import the highlight-search-term ES module and then export the highlightSearchTerm-function to the global scope. However, my knowledge about doing this the right was is limited.
• ES Modules cannot be easily imported in our *.js files. It would be nice to import the highlightSearchTerm directly into bibsearch.js. To achive that, I can only use hardcoded URLs (no liquid syntax), so that it would not work with offline/download mode. Could maybe be solved by downloading the file directly and putting it into the assets folder.
• Currently not supported in Firefox, but it will get support soon. So, this is not an issue IMHO.

What do you think?

[CheariX]

Update.

I integrated highlight-search-term.js directly. Now, it can be easily integrated as a module.
The code looks much cleaner.

Also, I set the old non-highlighting filter function as a fallback in case the browser does not support the API.

I'm pretty happy (=done) with the code now.

One question left: Can we somehow enable ES6 support in Uglifier (that is the reason why the checks did not pass)? Or do we really want to stay with old ES5 syntax?

[george-gca]

I will try to take a proper look at this this weekend.

[CheariX]

Thank you, @george-gca. Looking forward to hear your opinion on this PR.

About the failed check:

We can change node.textContent?.XYZ (ES6 Syntax) to something like node.textContent && node.textContent.XYZ to pass uglify checks, see e.g. a0d51f7. However, I’d argue that it would be nice to allow this syntax because it is much better to read.

[CheariX]

I changed ES6 syntax to ES5 compatible syntax so that Uglifier does not fail.

In the future, it would be nice to allow ES6 Syntax, see #2548.

@george-gca: is there anything else I can do to push this forward?

[george-gca]

I just need to make some time to look throught this PR. I'll do it this weekend for sure.

[george-gca]

Sorry for the delay on this. This is a very nice addition indeed.

Can we somehow enable ES6 support in Uglifier?

I think so. Some code updates might be needed, but it would be nice to keep it as up-to-date as possible with the latest best practices. There was also a huge effort (#741) to update some of the dependencies of the template (aka bootstrap), but that was never finished. I hope someday I will have the time to tackle this before it gets more difficult to do it. Maybe you could help on some of these?

The search box is optional. It can be simply removed if anyone does not like it.

I believe it is a better idea to create a way to easily disable it, like a setting in _config.yml. Something like bib_search: true, but it could be another name, I didn't give it much thought. So this way one could avoid drawing the search bar and also import the js files.

[CheariX]

The search box is optional. It can be simply removed if anyone does not like it.

I believe it is a better idea to create a way to easily disable it, like a setting in _config.yml. Something like bib_search: true, but it could be another name, I didn't give it much thought. So this way one could avoid drawing the search bar and also import the js files.

Nice idea. Introduced with 07d6e61

[george-gca]

Thanks for the contribution. It is always nice when a lot more people contribute to the project.