Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Pagefind Plugin #2568

Open
wants to merge 45 commits into
base: master
Choose a base branch
from
Open

Conversation

gerteck
Copy link
Contributor

@gerteck gerteck commented Aug 12, 2024

What is the purpose of this pull request?

  • Documentation update
  • Bug fix
  • Feature addition or enhancement
  • Code maintenance
  • DevOps
  • Improve developer experience
  • Others, please explain:

Overview of changes:

This PR introduces the PageFind plugin to the project, enabling full-text search capabilities for static sites. Read about PageFind.

Using the Pagefind plugin allows users to search through all content on the webpage entirely offline without signing up and/or using an online external search service (e.g. Algolia).

This PR builds on #2477

This relates to #205

Anything you'd like to highlight/discuss:

In brief, PageFind plugin indexes all files during the build process and generates the necessary search data. This data is then bundled into static assets that are served alongside the site. The assets are saved directly into the output directory (/_site/pagefind), and the plugin script is designed to load these assets dynamically.

  • Still facing slight optimization difficulties
    • how to access the generated pagefind assets within the plugin script, due to MB's behavior of changing the file path for scripts and links in Plugins. Investigating. Current workaround to directly save and load these assets for default UI into MarkBind first, but can be much more efficient.

Addressed Concerns:

  • As PageFind's default UI doesn't seem to fit into the theme of MarkBind, made custom vue components
  • Added option to use default UI over MB-styled UI

Additional Tasks / To-do:

  • Seek PR Review and testing
  • Update Documentation
  • Update Automated Testing

Possible Further Improvements:

  • Can optimize by debouncing search (Benefit vs cost of doing so)
  • Add max number of subresults to be shown as plugin option / component option

Testing instructions:

  1. Add pagefind plugin into site.json
...
"plugins": [
  "pagefind"
]
  1. In any page, add the vue component: <pagefind-searchbar/>

Other things you can try to play with:

  • Add <pagefind-searchbar defaultUI/>
  • Replace native search bar in layouts/default.md to <pagefind-searchbar menu-align-right/>

This is how it roughly looks like on a sample page:

image

Proposed commit message: (wrap lines at 72 characters)

Add PageFind Plugin


Checklist: ☑️

  • Updated the documentation for feature additions and enhancements
  • Added tests for bug fixes or features
  • Linked all related issues
  • No unrelated changes

Reviewer checklist:

Indicate the SEMVER impact of the PR:

  • Major (when you make incompatible API changes)
  • Minor (when you add functionality in a backward compatible manner)
  • Patch (when you make backward compatible bug fixes)

At the end of the review, please label the PR with the appropriate label: r.Major, r.Minor, r.Patch.

Breaking change release note preparation (if applicable):

  • To be included in the release note for any feature that is made obsolete/breaking

Give a brief explanation note about:

  • what was the old feature that was made obsolete
  • any replacement feature (if any), and
  • how the author should modify his website to migrate from the old feature to the replacement feature (if possible).

jingting1412 and others added 30 commits March 27, 2024 00:42
@gerteck gerteck marked this pull request as ready for review January 14, 2025 11:47
@gerteck gerteck changed the title Add PageFind Plugin (Re-PR) Add PageFind Plugin Jan 14, 2025
@gerteck gerteck changed the title Add PageFind Plugin Add Pagefind Plugin Jan 14, 2025
@damithc
Copy link
Contributor

damithc commented Jan 14, 2025

Thanks for picking this @gerteck
It is indeed a good addition to MarkBind if we can have a decent built-in full-text search, instead of having to rely on external search services as we do now.

@lhw-1
Copy link
Contributor

lhw-1 commented Jan 15, 2025

As discussed previously, this is a fantastic addition to MarkBind!

Something to consider after this PR would be the usability aspect. Given that the existing search function (by header) differs from this one (by text), with neither being replacements for the other (and with valid use cases for both), what we should consider is:

How do we increase the visibility of this plugin? Is documentation sufficient for users to be able to find and use this plugin, or should we actively include it in our templates? (And if so, how do we arrange / prioritise the two search functions in the UI?)

As mentioned during the group discussion, SICP JS in Source Academy handles this problem by putting both search functions side-by-side. By this train of thought, it might be worthwhile to make both of the search functions into modular components.

@gerteck
Copy link
Contributor Author

gerteck commented Jan 15, 2025

How do we increase the visibility of this plugin? Is documentation sufficient for users to be able to find and use this plugin, or should we actively include it in our templates? (And if so, how do we arrange / prioritise the two search functions in the UI?)

As mentioned during the group discussion, SICP JS in Source Academy handles this problem by putting both search functions side-by-side. By this train of thought, it might be worthwhile to make both of the search functions into modular components.

Thank you for the insights! Completely agree with the further considerations for the feature addition. I think it relates with @2529 and there will be a need for further analysis of the cost and benefit of making certain plugins default and increasing the usability/visibility of the features of each plugin.

The integration of both search functions as modular components could also be new issues to investigate and discuss!

Will work on adding documentation for the plugin after further discussion and confirmation on the feature 👍

@damithc
Copy link
Contributor

damithc commented Jan 15, 2025

To add, the ideal outcome is that this plugin replaces both the current search (i.e., headers only) feature and the need to use third party search. The ideal is if this plugin can do what Algolia currently does for us (in terms of what user sees -- example https://nus-cs2103-ay2425s2.github.io/website/ ), or at least come close.

@lhw-1
Copy link
Contributor

lhw-1 commented Jan 15, 2025

To add, the ideal outcome is that this plugin replaces both the current search (i.e., headers only) feature and the need to use third party search.

During the discussion with @gerteck, the point made was that searching by header and searching by text have somewhat different use cases and each of them might be necessary for different situations (especially since MarkBind tends to be header-heavy given its use case). If the initial goal was to replace the current search with this plugin, then I think we should consider one of these:

  1. Either make this new plugin into a component & make it the default search on current templates (for easier use & to establish it as the "default"), or:
  2. Find a way to integrate the two components into one (maybe there can be an overarching search component with a toggle between header-search and text-search via a prop?)

Of course, keeping in mind that this is out of scope for this PR & we may have to open a new issue to continue discussing this (@gerteck feel free to start this discussion issue), also given this comment:

there will be a need for further analysis of the cost and benefit of making certain plugins default and increasing the usability/visibility of the features of each plugin.

@gerteck
Copy link
Contributor Author

gerteck commented Jan 27, 2025

After discussion last week, I realized that if we can get a fully functional search bar that does a full text search, it would probably be a better idea to just do away with the index/header search, since it was a placeholder from the start.

I found an interesting adaption of Pagefind in a very similar fashion to Algolia, see here

Using the vue command palette package, it would not be too hard to recreate the algolia UI sample implementation here (open source chinese blog, can do ctrl + k to open command palette, search "test") and effectively replace the current search bar with that.

However, the issue is that these packages are all in Vue 3 making it incompatible with the current Vue2 library. I think it may be time to tackle the Vue 2 -> Vue 3 migration for greater longevity of the current components and future new components if developed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants