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

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

Draft
wants to merge 6 commits into
base: master
Choose a base branch
from
Draft

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

wants to merge 6 commits into from

Conversation

JonUK
Copy link
Contributor

@JonUK JonUK commented Mar 9, 2020

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)

JonUK and others added 5 commits February 28, 2020 00:00
Added a "hidden until focussed" skip link as the first interactive element on the page
Tabbing through the page, it takes over 100 key presses to get to the main content due to the "Tags" links and the GitHub "Avatar" links.
https://webaim.org/techniques/skipnav/

Added a `<main>` element to the page as this landmark can be used by assistive technology
Pull latest from upstream
@vercel
Copy link

vercel bot commented Mar 9, 2020

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

{% set js %}
{% include "js/search.js" %}
{% endset %}
{{ js | safe }}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can do jsmin here to reduce the JS size down.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we should def do that. :)

@stefanjudis
Copy link
Owner

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
Copy link
Contributor Author

JonUK commented Mar 16, 2020

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
Copy link
Owner

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
Copy link
Contributor Author

JonUK commented Mar 17, 2020

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
Copy link
Owner

Cool. Thanks for writing this down.

  1. ✅ (the dynamically rendered result will match the server-rendered version)
  2. ✅ 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
Copy link
Contributor

niksy commented Jun 30, 2021

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

@Ryuno-Ki
Copy link
Contributor

Ryuno-Ki commented Jul 1, 2021

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

@ndom91
Copy link
Contributor

ndom91 commented May 1, 2022

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
Copy link
Owner

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. :)

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