Add a filter to the command list. Resolves #7 #8

moonglum · 2024-03-24T22:34:37+01:00

moonglum commented

2024-03-24 22:34:37 +01:00

Filter the list of commands with a search term entered by the user.

Implemented using custom elements, filtering the elements directly.

Short screencast showing how it works attached.

Filter the list of commands with a search term entered by the user. Implemented using custom elements, filtering the elements directly. Short screencast showing how it works attached.

Screencast from 2024-03-24 22-30-11.webm

333 KiB

ddevault commented

2024-03-24 22:54:19 +01:00

Nice work! Can you make a couple of changes?

Remove headings with no results
Put some styling on the search box, maybe import some pieces ala-carte from bootstrap?

Nice work! Can you make a couple of changes? * Remove headings with no results * Put some styling on the search box, maybe import some pieces ala-carte from [bootstrap](https://getbootstrap.com/docs/5.3/forms/floating-labels/)?

ddevault reviewed

2024-03-24 22:55:21 +01:00

layouts/partials/commands/list.html Outdated

					
				@ -32,3 +24,1 @@

				  </li>

				  {{ end }}

				</ul>

				<filtered-list filter-field="#filter-commands">

I admit I haven't kept up with web stuff in a while. What's going on here? How broadly compatible is your approach with various web browsers?

In the JavaScript code, I define a custom element. That‘s basically a way to invent new HTML tags. They must contain a - in the name which makes them forward-compatible as standard elements are not allowed to contain a -. They are supported by 96% of installed browsers world-wide. If you prefer, I can hide the filter bar if the browser doesn‘t support them, or the JS did not load for some reason. The custom elements themselves do no harm, as browsers do treat unknown elements basically as spans.

The JS code runs for every time the element is defined. You can imagine it a bit like the implementation of that element.

If you are interested to learn more, MDN has a nice tutorial.

Dispatching custom events has been implemented for a long time. The filter field dispatches a custom events on itself when you key up on the field. The filter lists listen on that event, and then filter their children.

Let me know if you have more questions about the approach.

In the JavaScript code, I define a custom element. That‘s basically a way to invent new HTML tags. They must contain a `-` in the name which makes them forward-compatible as standard elements are not allowed to contain a `-`. [They are supported by 96% of installed browsers world-wide](https://caniuse.com/custom-elementsv1). If you prefer, I can hide the filter bar if the browser doesn‘t support them, or the JS did not load for some reason. The custom elements themselves do no harm, as browsers do treat unknown elements basically as spans. The JS code runs for every time the element is defined. You can imagine it a bit like the implementation of that element. If you are interested to learn more, [MDN has a nice tutorial](https://developer.mozilla.org/en-US/docs/Web/API/Web_Components/Using_custom_elements). Dispatching custom events has been implemented for a long time. The filter field dispatches a custom events on itself when you key up on the field. The filter lists listen on that event, and then filter their children. Let me know if you have more questions about the approach.

Thanks for the detailed explanation!

ddevault marked this conversation as resolved

moonglum commented

2024-03-24 23:33:04 +01:00

Thanks, Drew! Glad you like it! I’ll add filtering the headlines and styling the fields tomorrow 👍

moonglum commented

2024-03-25 11:11:54 +01:00

@ddevault Addressed all three pieces of feedback. What do you think?
I chose to go with visibility: hidden for the filter field so we do not have a layout shift when the JS is loaded (which would happen if we go with display: none).

One thing I'm not sure about:
I'm not entirely sure if we should also hide the entries in the table of contents on the right for the hidden entries.

@ddevault Addressed all three pieces of feedback. What do you think? I chose to go with `visibility: hidden` for the filter field so we do not have a layout shift when the JS is loaded (which would happen if we go with display: none). One thing I'm not sure about: I'm not entirely sure if we should also hide the entries in the table of contents on the right for the hidden entries.

ddevault commented

2024-03-25 12:03:28 +01:00

This is looking good, thanks! I have some more feedback.

When categories disappear, the space they occupied is still shown on the page. See attachment.

After reviewing this, I think the usability would be improved if we removed the categories entirely while searching and alpha-sorted all of the results together. What do you think?

I also think we can make some improvements to the search box appearance:

diff --git a/assets/_custom.scss b/assets/_custom.scss
index ce8621581..13eba4e0b 100644
--- a/assets/_custom.scss
+++ b/assets/_custom.scss
@@ -80,16 +80,27 @@ article h1 .subtitle {
 filter-field {
 	visibility: hidden;
 
+	input, label {
+		display: block;
+		width: 100%;
+	}
+
+	input {
+		padding: .5rem 1rem;
+		border: 1px solid #333;
+		border-radius: .25rem;
+		background: transparent;
+		color: var(--body-font-color);
+		transition: box-shadow 0.1s linear;
+		line-height: 1.5em;
+	}
+
+	input:focus {
+		box-shadow: 0 0 2px 1px var(--color-link);
+		outline-style: none;
+	}
+
 	&.active {
 		visibility: unset;
 	}
 }
-
-/* input field from hugo-book */
-.text-field {
-	padding: .5rem;
-	border: 0;
-	border-radius: .25rem;
-	background: var(--gray-100);
-	color: var(--body-font-color);
-}
diff --git a/layouts/partials/commands/list.html b/layouts/partials/commands/list.html
index 6612d2989..89c28eba9 100644
--- a/layouts/partials/commands/list.html
+++ b/layouts/partials/commands/list.html
@@ -38,7 +38,7 @@
 
 <filter-field id="filter-commands">
   <label for="search-field">Filter</label>
-  <input id="search-field" class="text-field">
+  <input id="search-field" class="text-field" placeholder="Search commands">
 </filter-field>
 
 {{ range $groups }}

I'm not entirely sure if we should also hide the entries in the table of contents on the right for the hidden entries.

I don't think we need to worry about this.

Follow-ups for a future ticket:

Encode the search terms in the URL fragment
Fuzzy match and order by relevance

This is looking good, thanks! I have some more feedback. When categories disappear, the space they occupied is still shown on the page. See attachment. After reviewing this, I think the usability would be improved if we removed the categories entirely while searching and alpha-sorted all of the results together. What do you think? I also think we can make some improvements to the search box appearance: ```diff diff --git a/assets/_custom.scss b/assets/_custom.scss index ce8621581..13eba4e0b 100644 --- a/assets/_custom.scss +++ b/assets/_custom.scss @@ -80,16 +80,27 @@ article h1 .subtitle { filter-field { visibility: hidden; + input, label { + display: block; + width: 100%; + } + + input { + padding: .5rem 1rem; + border: 1px solid #333; + border-radius: .25rem; + background: transparent; + color: var(--body-font-color); + transition: box-shadow 0.1s linear; + line-height: 1.5em; + } + + input:focus { + box-shadow: 0 0 2px 1px var(--color-link); + outline-style: none; + } + &.active { visibility: unset; } } - -/* input field from hugo-book */ -.text-field { - padding: .5rem; - border: 0; - border-radius: .25rem; - background: var(--gray-100); - color: var(--body-font-color); -} diff --git a/layouts/partials/commands/list.html b/layouts/partials/commands/list.html index 6612d2989..89c28eba9 100644 --- a/layouts/partials/commands/list.html +++ b/layouts/partials/commands/list.html @@ -38,7 +38,7 @@ <filter-field id="filter-commands"> <label for="search-field">Filter</label> - <input id="search-field" class="text-field"> + <input id="search-field" class="text-field" placeholder="Search commands"> </filter-field> {{ range $groups }} ``` > I'm not entirely sure if we should also hide the entries in the table of contents on the right for the hidden entries. I don't think we need to worry about this. --- Follow-ups for a future ticket: * Encode the search terms in the URL fragment * Fuzzy match and order by relevance

scrot.png

184 KiB

moonglum force-pushed filter-commands from 6178d208c9

builds.sr.ht Job failed

Details

to 5fbfc2bcb2

builds.sr.ht Job failed

Details

2024-03-25 22:28:34 +01:00

Compare

moonglum commented

2024-03-25 22:33:36 +01:00

Thank you kindly for your feedback!

Fixed the bug with the empty space 👍
Added your CSS changes, and the placeholder text. I like it 👏
Rebased & Squashed

Will play around with the idea of alpha sorting without categories, and get back to you 👍

The failed build is just the publish step, so I guess I can ignore that, right?

Thank you kindly for your feedback! 1. Fixed the bug with the empty space 👍 2. Added your CSS changes, and the placeholder text. I like it 👏 3. Rebased & Squashed Will play around with the idea of alpha sorting without categories, and get back to you 👍 The failed build is just the publish step, so I guess I can ignore that, right?

ddevault force-pushed filter-commands from 5fbfc2bcb2

builds.sr.ht Job failed

Details

to 83b46f2420

2024-03-26 10:07:07 +01:00

Compare

ddevault merged commit 83b46f2420 into main

2024-03-26 10:08:43 +01:00

ddevault commented

2024-03-26 10:08:53 +01:00

Thank you!

The failed build is just the publish step, so I guess I can ignore that, right?

Yep, no big deal.

Thank you! >The failed build is just the publish step, so I guess I can ignore that, right? Yep, no big deal.

moonglum deleted branch filter-commands

2024-03-26 11:37:58 +01:00

moonglum commented

2024-03-26 11:40:13 +01:00

Thanks, Drew! I'll put the ideas of improving this on my list (hiding the headings when searching, fuzzy matching, ordering by relevance and encoding the search in the fragment)

👍 1

Sign in to join this conversation.

No reviewers