Dynamic search results as user types into Input - stopping after first character

Hi gang. I have a list of things where the full list appears on page load. There’s a search box up top which I want to use to let users filter the results. I’m having some funky, inconsistent behavior which seems to be timing and/or order-of-operation related. Hoping to get some best practice suggestion(s) here…

The data is a repeating group of things and it uses Do a Search looking at the input coupled with the current user. Here’s the thing: when I input letters one at a time, it seems to only respond/capture the first letter. If i hit ENTER, or I paste in the entire search term, the results are exactly what I’d expect. but regular speed typing, it only matches on the first letter.

I have 2 workflows at play here. One that fires (“every time” when true) when input is not empty:
when-input-not-empty

And another that fires when input “value has changed”
when-value-changes

Is there a smarter or more reliable way to do this? Thanks!

I should add that when in debug mode, I have verified that the workflow(s) are only triggering at the first character input. Entering subsequent letters in the Input doesn’t bring up the debugger step-into, run slow, etc.

My theory is that the moment i type that first character, it’s setting my custom state (“mega-query”) with that first letter… and subsequent letters are missed while that workflow finishes executing. i tried adding a pause as step 1, both 500 and 1000 ms, but it didn’t help.

What I really want to happen is "when the user finishes typing, look at what was entered and put THAT into my custom state (mega-query). Rather than trying to update it 4 times in rapid succession if someone types 4 characters.

Thanks in advance!

Hello @ThatFizzGuy

Why not use a search box element instead of an input?

The input is in a reusable header at the top of the page. My repeating group is a full page table. I don’t think a Search Box fits the bill for my situation. Thanks though

Not sure I understand how an RE header and a full page RG affects the decision to use a search box or not. :grimacing:

I’ll take another look at them. I thought they create a drop down-ish appearance which wouldn’t work for me. But if that’s not the case and it can look and behave like a regular input then I’ll give it a look. Thanks

Update: closer to desired behavior when I have workflow run “when condition is true” triggered by input:number of characters > 2 (i.e. 3 or more characters). It’s still only running once, but at least now it’s using 3 characters instead of 1. Still, I have to think I’m doing something wrong. There must be a way to have it trigger again if the user keeps typing (say, 5 or 6 chars) for an even more accurate filtering. I suppose I could create another workflow for >3 and one for >4 etc, but that hardly seems efficient.

@cmarchan - i looked at SearchBox and it does seem to want to function like a drop-down with “choices.” Not my use case. Do you have an example where it’s behaving like a standalone input field and a repeating group elsewhere on the page looks to it for its filtering guidance? thx

Hello!

I see.

Using a button with an input is not an option?

I actually have a button and things DO work fine when it’s clicked. Same behavior as if/when the user hits enter. But on a mobile device, I’d prefer it to just work like a type-ahead as they type.

Solved here: