Quick answer

I built InputPrice.vue for PreBook, a price input that reformats the visible string on every keystroke to match one of four separator conventions, while keeping the text cursor exactly where the user left it. The hard part wasn't the formatting - it was doing that live, per keystroke, without the field fighting the person typing into it.

TL;DR

Problem	A price field has to show locale-correct grouping/decimal separators live while typing, without corrupting the value or the cursor
What I did	Built a Vue component that reformats the display string on every input event and repositions the cursor based on separator count
Why it mattered	PreBook's payment settings support four separator conventions - a native <input type="number"> supports none of them correctly
Team	Solo

The problem

A price field looks simple until you try to make it usable:

• 1234.56 is technically valid but hard to scan - a merchant needs 1,234.56
• Adding thousands grouping means two strings for one value: what's shown on screen, and the plain number sent to the backend, kept in sync on every keystroke
• A native number input enforces one separator convention, browser-wide, and rejects anything else
• PreBook lets each store pick its own separator convention, so type="number" was never going to work - it had to be a custom component

Why locale ambiguity is genuinely hard

• 1.234 isn't one number - it's two, depending on the convention reading it: one thousand two hundred thirty-four under dot-comma, or one-point-two-three-four under comma-dot
• There's no way to resolve that by inspecting the characters - the component has to be told which convention is active and stick to it
• InputPrice.vue keeps a separatorMap for all four conventions PreBook supports (Comma-Dot, Dot-Comma, Space-Dot, Space-Comma), and every format/parse call reads from the store's price_separator setting
• The cycle: format for display, strip back to a plain decimal on every keystroke, emit upward. Format, strip, emit, repeat

Keeping the cursor stable

• Reformatting on every keystroke can change the string's length ahead of the cursor - typing a digit that pushes the integer part from three digits to four also inserts a new thousands separator
• If the cursor just gets restored to its old index, it now sits one character short of where the user left it, so it visibly jumps backward every few keystrokes
• The fix: compare how many thousands separators exist before and after each reformat. If a new one appeared ahead of the cursor, nudge the cursor forward by one; otherwise leave it alone
• A small correction, but it's the difference between a field that feels broken and one that doesn't - and it only shows up once you test with real multi-digit prices, not single test values

FAQ

Why not just <input type="number">? It enforces one separator convention browser-wide, can't be configured per store, and rejects grouped thousands or a locale-specific decimal mark. Wrong problem for what PreBook needs. Why reformat on every keystroke instead of only on blur? Formatting only on blur leaves the field unreadable the entire time someone's typing - exactly when a merchant most needs to catch a mistyped digit. Live reformatting costs cursor-stability work, but that trade was worth it. Why did the separator bug keep coming back after the "optimize" commit? I was testing one locale convention at a time instead of running all four through each change - a coverage gap, not a one-off mistake. Why keep all four separator conventions in one component instead of splitting them out? One separatorMap means the reformat-and-cursor logic is written and fixed once, for every locale, instead of that same bug class multiplied across four separate components.

Part of the A Shared Component Architecture for a WordPress Booking Plugin series →