Search bar HTML/CSS only

[dragontheory]

No description provided.

[bob2517]

Possibly don't need the search submit button if this is going to be based on a keystroke event. A "clear" button might be useful though, to clear the search.

I'll do the functionality for the search, and it should be clearer to see what's needed then.

[dragontheory]

Possibly don't need the search submit button if this is going to be based on a keystroke event. A "clear" button might be useful though, to clear the search.

I'll do the functionality for the search, and it should be clearer to see what's needed then.

Ok. Thank you for answering my questions. Appreciate your patience and helping me understand.

[bob2517]

Cool. What do you want me to search on? I can search on any field or a combination of fields, or just the alias?

I'll set it up for just the alias and the real supe name at the moment, and you can let me know if you want me to extend it to include affiliations, or whatever you like.

[bob2517]

Almost done on this, pending a clear button or whatever gets added next. I've updated the API and got the search results returning the correct stuff. Just a bug fix to do, get the list to go back to default when the results are emptied, then a bunch of testing. Should have this done in the next hour or two, not accounting for dinner.

[bob2517]

You would think that the search would be complicated, but actually it's just this event:

	/* User search. Detect a key stroke in the search input field and decide what to do. */
	app-search > input:input {
		@if not-empty(self) && min-length(self 3) {
			/* Set the search value to a variable if the search string has at least 3 characters. */
			$srchValue: "{@@value}";
		} @else if empty(self) {
			/* Clear the search variable if there is nothing in the search box. */
			$srchValue: "";
		} @else {
			/* Don't do anything. */
			exit;
		}
		/* Set the page number to 1. */
		$viewPageNo: 1;
		/* Fetch the search results using the existing method of populating the list. */
		panel-list[data-search-results] {
			trigger: fetchRows;
		}
	}

Plus a change to the fetchRows ajax command to include the search string as one of the variables.

I've got something else to fix, but that's the basic code. It works really nicely because the UI is already set up to handle things.

It's cool that ACSS can handle the conditionals in the if statement, alongside regular JavaScript. That makes things a lot simpler to code. I did originally have 3 events, but I condensed it into one to re-factor it.

[bob2517]

I just committed what I've got so far, but there's still a bug I need to fix. The page number is not setting itself correctly yet. The rest is fully functional though and it's really cool to be able to search for specific supes.

[bob2517]

Also, it's not handling "no search results" yet. The pagination goes a bit crazy when that happens.

[bob2517]

Done another commit that fixes the page numbers. Just the "no search results" to sort out now, which is just a case of hiding the pagination, in terms of the expected result.

[bob2517]

Another thing that needs sorting out is when you hit refresh, the input field is remembering the search. It's probably worth change the url to involve the pagination parameters and getting the page refresh to grab the same list that was displayed before the refresh button was hit. That's quite easy to do - just store the variables in local storage and set them up on body init. The rest should take care of itself. I'll do that after I fix this last bug on the search.

[dragontheory]

Cool. What do you want me to search on? I can search on any field or a combination of fields, or just the alias?

I'll set it up for just the alias and the real supe name at the moment, and you can let me know if you want me to extend it to include affiliations, or whatever you like.

I think a combination of the fields, alias and affiliations.

[dragontheory]

Done another commit that fixes the page numbers. Just the "no search results" to sort out now, which is just a case of hiding the pagination, in terms of the expected result.

Thank you for that.

When I type in "Bom" the results reduce to 3, which is great! But the page numbers to the right of the "Search Results" don't change.

Also the second number should probably represent how many match the search text string, since the first number represents the number of visible results. For example, [ 5 / 10 ], would represent, showing 5 out of 10 possible or returned results.

[dragontheory]

Another thing that needs sorting out is when you hit refresh, the input field is remembering the search. It's probably worth change the url to involve the pagination parameters and getting the page refresh to grab the same list that was displayed before the refresh button was hit. That's quite easy to do - just store the variables in local storage and set them up on body init. The rest should take care of itself. I'll do that after I fix this last bug on the search.

Yes. Let's do that. That is phase one of a "preferences layer" that I would like to develop for all the various ways users will be able to customize the UI. Ultimately, not this time around unless it's easily doable, users will be able to customize the UI, save their customizations as a name (text string) of some sort, close out their browser, shut off their machine, and come back the next morning and bring up the app exactly where they left off. With everything exactly where they left off. Even what pagination page and if they had the right aside panel open or closed and if they had the form partially filled out. If they don't give a name to save, it auto-saves with today's date and time down to the second to make sure the name is always unique and in order. This would happen if the power was suddenly lost also. Is that overkill?

[bob2517]

When I type in "Bom" the results reduce to 3, which is great! But the page numbers to the right of the "Search Results" don't change.

Are you looking at the latest commit? It works for me offline and on the GitHub link.

Also the second number should probably represent how many match the search text string, since the first number represents the number of visible results. For example, [ 5 / 10 ], would represent, showing 5 out of 10 possible or returned results.

Ok, will do.

Is that overkill?

For a regular website, it's overkill. It's not a problem that needs solving in practical terms. Not in 2022, anyway. In the future it's more of a thing, but then I probably shouldn't be saying that as it may affect the timeline.

For a device app that needs to work offline, it is absolutely not overkill, but it depends on what you are making. It would be good to have it so forms can be saved when there is no internet connection, and update when there is one, and then you're getting into queueing jobs from the browser. It's something you would add after you had CRUD, login, form saving security, etc. all working, so you know the design of what you need to implement in local storage in the browser. None of this is particularly easy to do, and it does require some experience to do it properly and securely.

Saving the current state of things without paying attention to the forms, is however very easy to do.

[bob2517]

I think a combination of the fields, alias and affiliations.

The API has been amended to do this. I'm mid working on the infinite scrolling, but will add the highlight for the search term.

I'll add the class "highlight", like they do in that codepen.

Do you want to get a "highlight" class set up in CSS for it?

[bob2517]

It doesn't have to be today - I'll set up a temporary one for me to work with.

[bob2517]

Rather than using a span, like they do in the example, I'm using <highlight-term></highlight-term>. Span already has special rules set up. I've got it working - will commit when I get the infinite scrolling to a good point.