Changed price filter to use text input

[tyleralsbury]

PR Summary:

Changes the price filter on collections and search results to use a text input instead of a number input. This will allow it to use any price formatting, providing a better experience for buyers on stores that use comma style decimals.

Why are these changes introduced?

There is a significant amount of technical complexity in the previous solution. It was implemented that way to try to take advantage of the type="number" input but that approach came with a lot of downsides. In particular, comma decimals were not supported, but also buyers couldn't use thousands separators as they typed.

What approach did you take?

Changed the input to type="text" and made some adjustments to the Javascript to only allow the buyer to type relevant characters and use meta key functions.

I also consolidated the price filters into a snippet to remove the code duplication between the mobile and desktop filters and made the active filter look better by adding a   so that the - wasn't stuck to the max value.

Other considerations

• Mobile should work properly due to the inputtype attribute. This would have been a problem with the text input type otherwise
• JS is handling suppressing improper characters. I whitelisted all meta key functions so things like copy/paste and select all should still work.
• I removed the ability to step through values. This comes for free with the number input type, but would take a pretty decent chunk of overhead to successfully implement in a way that retained the correct currency formatting
• I'm not doing full validation of the input. Again, the lack of a way of testing against the currency is a problem for this. Instead, I will pass any value that the user successfully types and the server-side filtering logic can apply to it. From what I observed, a value like 11,11,11 will return 0 for the minimum input and the highest price for the max input. Any incomprehensible value should work this way, which seems good enough to me for us to not have to worry about doing any complex validation logic on the theme side. If we do want validation on the theme side, then acceptable patterns should be sent back in Liquid so that we don't have to figure them out on the theme. I do think it's overkill, though.

Decision log

#	Decision	Alternatives	Rationale	Downsides
1

Visual impact on existing themes

It is mostly the same. The only real difference should be the removal of the step controls.

Testing steps/scenarios

• Go to a collection or search results page
• Play with the price filter - type numbers, try to type inappropriate characters (letters, symbols), test meta key functionality (copy/paste, select all, etc...), ensure the prices all appear as expected.

Demo links

• Store
• Editor

Checklist

• Added PR summary for release notes
• Requested review from UX (Only for changes that are affecting the experience or perceivable visual details)
• Created a ticket for the help.shopify.com documentation team about updates to theme settings. (Internal-only task)
• Followed theme code principles
• Linted with Theme Check
• Tested on mobile
• Tested on multiple browsers
• Tested for accessibility

[tyleralsbury]

I believe this is a full list of keys that matter. Should be tested for completeness.

[NathanPJF]

Should add apostrophe ', it's one of the supported currency formats https://help.shopify.com/en/manual/markets/pricing/currency-formatting

[NathanPJF]

Interesting that I was able to press Esc without issue even though Escape is it's own value. 🤔 MDN link. I wonder if some other event listener on the modal caught this, and the event was allowed to propagate up. Regardless, worth adding Escape to the list.

[tyleralsbury]

A weight off my shoulders for this to be gone. 😄

[NathanPJF]

I was literally thinking "How did currencies become the new payment logos!?"

[NathanPJF]

Approved with comments. I tested the suggested change

🎩 Tophatted on a store with Chilean Peso and another with Euros using various currencies. Nice work!

Comment outside the scope of this PR: It's pretty difficult to use this input IMO because of how quickly a change event is registed and submits the new price. I have to type super quickly to avoid 5 being submitted when I really wanted 50 - same applies for the mobile experience. Feels like there should be a "submit" button of some sort. The Mobile drawer already has an "apply" button, which doesn't seem to need to be used. Examples seen in the wild:

• Best Buy CA : https://screenshot.click/19-55-mu7u7-j02sr.png
• Amazon.com : https://screenshot.click/19-48-43ffd-sbuhm.png
• Home Depot CA: https://screenshot.click/19-57-bunf4-x7f8o.png

A range slider could be another approach, but the UX there is too finicky IMO. And it takes just one product out-liner price to make the range input seem silly - like having one $5000 product in a collection when most are $100 to $200.

[NathanPJF]

Should add apostrophe ', it's one of the supported currency formats https://help.shopify.com/en/manual/markets/pricing/currency-formatting

[NathanPJF]

Interesting that I was able to press Esc without issue even though Escape is it's own value. 🤔 MDN link. I wonder if some other event listener on the modal caught this, and the event was allowed to propagate up. Regardless, worth adding Escape to the list.

[ludoboludo]

I'm wondering if there is a11y announcement of the inputs that should be tweaked to be clearer as there are no clues about the fact that it's only supporting numbers. Except the summary that mentions it's a price filter.

Other wise other than addressing Nathan's comment ideally before merge, it seems good 👍

I'm curious about one thing. When I change to different markets/currency it removes the price filter. Is that something coming from markets/search & disco app?

[tyleralsbury]

I'm wondering if there is a11y announcement of the inputs that should be tweaked to be clearer as there are no clues about the fact that it's only supporting numbers. Except the summary that mentions it's a price filter.

I think it's probably okay since prices should be numerical.

[tyleralsbury]

@NathanPJF @ludoboludo thanks for the reviews. I made most of the changes, just didn't do anything for the a11y (I think it should be okay since price is only numbers).

Also, I changed the delay for the debounce from 500ms to 800ms. @NathanPJF, this should alleviate some of the need to type super fast to not have it trigger an update before you're done. Let me know how this feels.

[melissaperreault]

I had similar concerns about submitting the form this quickly in this new form, there is a difference in the experience for sure with this change, even with the latest delay change. A better UX would be to implement a submit button to avoid distraction for buyers using mouse/keyboard or just keyboard. Reference video walking through the pain.

cc. @kjellr @Oliviammarcello FYI for your scope of work.

[ludoboludo]

Seems good to me 👍

[tyleralsbury]

I had similar concerns about submitting the form this quickly in this new form, there is a difference in the experience for sure with this change, even with the latest delay change. A better UX would be to implement a submit button to avoid distraction for buyers using mouse/keyboard or just keyboard. Reference video walking through the pain.

cc. @kjellr @Oliviammarcello FYI for you scope of work.

I don't really want to increase the scope for this PR in particular to include a pattern like that, but something I do notice is that the focus doesn't return to the specific element you're typing in now, where in the past it seems like it did. I will see if I can resolve that because it would alleviate the issue a bit.

[tyleralsbury]

I pushed a small commit to retain focus when typing in a text input. This should help make the auto-submit feel better.

[melissaperreault]

Thank Tyler! 🚢

I also observed an additional win on the experience buyers will get with this update: the input will display the query they made instead of auto-updating to the highest price available. I think it's a win in clarity! (Video reference)

[HendrikShopify]

adjustToValidValues(input) {
    const value = Number(input.value);
    const min = Number(input.getAttribute('data-min'));
    const max = Number(input.getAttribute('data-max'));

    if (value < min) input.value = min;
    if (value > max) input.value = max;
  }

This function could break if the input value uses a comma (,) instead of a dot (.) as a decimal separator, leading to NaN. To fix this, I added replace: ",", "." to data-max="{{ filter.range_max | money_without_currency }}" to ensure correct formatting.