redict/redict.io
6
9
Fork
You've already forked redict.io
9

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

Merged
ddevault merged 1 commit from :filter-commands into main 2024年03月26日 10:08:43 +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.

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/)?
@ -32,3 +24,1 @@
</li>
{{ end }}
</ul>
<filtered-list filter-field="#filter-commands">
Owner
Copy link

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?

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

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

Thanks for the detailed explanation!

Thanks for the detailed explanation!
ddevault marked this conversation as resolved
Author
Owner
Copy link

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

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

@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.

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
moonglum force-pushed filter-commands from 6178d208c9
Some checks reported errors
builds.sr.ht Job failed
to 5fbfc2bcb2
Some checks reported errors
builds.sr.ht Job failed
2024年03月25日 22:28:34 +01:00
Compare
Author
Owner
Copy link

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?

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
Some checks reported errors
builds.sr.ht Job failed
to 83b46f2420 2024年03月26日 10:07:07 +01:00
Compare

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

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)

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)
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
redict/redict.io!8
Reference in a new issue
redict/redict.io
No description provided.
Delete branch ":filter-commands"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?