Proof of concept for client-side search support (WIP)

[JonUK]

Covered the bare-bones implementation of client-side searching (WIP)

• A new searchData.json feed file is being generated
• The searchData.json file is bundled up with the search code into a single JS file
• If the querystring q parameter exists, this is used to do initial filtering
• Search input has a debounced handler for filtering
• Search is not available on "tags" pages as already contains filtered items
• If JS is disabled, the search input is not displayed and no filtering applied

If this is an approach to go forwards with for search then:

TODO

• UI for search input and RWD handling needs to be improved
• History API used to change querystring when search term entered (allows bookmark / copy paste link)
• List title details "x of y items displayed" (user knows filter applied)

[vercel[bot]]

This pull request is being automatically deployed with ZEIT Now (learn more). To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://zeit.co/stefanjudis/tiny-helpers/5k7727egl ✅ Preview: https://tiny-helpers-git-fork-jonuk-master.stefanjudis.now.sh

[stefanjudis]

Thank you so much Jon for spending some time on this. :) I had a look at the overall functionality and have some concerns/questions. :)

Search is not available on "tags" pages as already contains filtered items

For me, this feels a little bit confusing. People entering on /css maybe will never see the search because they don't click on all as it shows almost 200 tools.

Search input has a debounced handler for filtering

Sweet! 👍

---

I still wonder if we can't leverage a function here and reuse the njk templates somehow. Could we implement a search/${query} route? I have in mind that people that are anywhere on the site can interact with the search. A person could then interact with it and after pressing and debouncing the first keystroke the URL will be updated client-site to tiny-helpers.dev/search/icons. This search page could have a different headline a la Showing 12 of 182 tools for term "icons".

The templates are already in a re-useable format so that we could set up a server-side variant and render the data in a function defined in now.json. Then we could also drop the document.write calls and figuring out if JS runs, because it'll work in any scenario. :)

What do you think of this?

[JonUK]

For me, this feels a little bit confusing. People entering on /css maybe will never see the search because they don't click on all as it shows almost 200 tools.

Yer... I wasn't too sure how to handle this as the tags filtering kinda overlaps with search filtering.

---

So are you thinking there is a real server-side rendered page using node.js that can serve up a filtered helpers page? If so, once a user accesses "/search/${query}" and the server returns the HTML with just the matching helpers, if the user types in a new search term, how are the new results displayed? Is a full page reload performed to get the server to return the HTML for the new page?

[stefanjudis]

If so, once a user accesses "/search/${query}" and the server returns the HTML with just the matching helpers, if the user types in a new search term, how are the new results displayed?

You have the data available in the JSON feed that this PR already includes. One could use this data to toggle a class on hidden helpers or re-render the list. :) The logic wouldn't differ much from what is included in this PR in the client already. :)

Does that make sense? :)

[JonUK]

I think I follow but just want to double-check...

Statements

1. There will be a server side rendered page with the URL "/search?q={query}" that will output the HTML for all helpers but via CSS attributes, will hide non-matches.
2. On the "All" page, when JS is enabled, changing the search term causes the URL to change via the use of the history API and via JS, just the matching helpers are displayed.
3. On the "All" page, when JS is disabled, entering a search term and then pressing "Enter" causes a form GET request to "/search?q={query}" (full page reload) for the server to render the new page.

Question With search being available on "tag" pages, when a term is entered, is it just the subset of helpers for the tag that are filtered? If yes, when JS is disabled, entering a search term and then pressing "Enter" I think will need to make a GET request of "/search?q={query}&t={tag}" to the server to handle the combined filtering.

[stefanjudis]

Cool. Thanks for writing this down.

1. ✅
2. ✅ (the dynamically rendered result will match the server-rendered version)
3. ✅ Exactly. Whatever happens it will just work. :) 🎉

With search being available on "tag" pages, when a term is entered, is it just the subset of helpers for the tag that are filtered?

I feel like we can ignore tags in that case and query all tools. If the form has a proper label like Search all helpers and the URL changes to /search i think it works and is understandable. :) What do you think?

[niksy]

What is the status of this PR? What can we help to get this merged?

[Ryuno-Ki]

I can see a merge conflict in .gitignore, @JonUK

[ndom91]

Just wanted to pop in here and mention you would definitely be accepted into the Algolia "DocSearch" opensource program (https://docsearch.algolia.com/).

Its a service they host / sponsor which scrapes static sites every 24hr and offers a nice simple search. You've probably seen it as that "Ctrl + K" search on many code documentation sites lately (for example tailwindcss and NextAuth.js are both using it).

[stefanjudis]

Thanks @ndom91. :) That's right, Algolia search is client-side only, though.

And while my opinion about JS-only search softened a little bit, I still think a server-side first approach way like a /search route using eleventy serverless (+ something with JS on top) would be best. 🙈

But yeah, I failed to handle this PR (sorry @JonUK :/) and I currently don't have the time to implement such feature, so I guess I'd be open for someone else taking over. :)