There are a lot of decisions to make in the first days of building a new application.

For B2B apps, the user experience tends to include a lot of forms and data input. When we get started it's common to reach for a pre-built library, often a popular free one. If we review the library at all, the process typically goes something like:

1. Am I using a UI library (react-bootstrap) that highlights a solution (Formik)? Use that one.
2. Review libraries on the internet:
   1. Search for my library and component name, ex: "react date"
   2. Scan the docs or github readme, does it look like it has the flexibility I think I need?
   3. Can I customize the colors?
   4. Are the last modified dates recent? (is it being actively supported)
   5. (sometimes) Is the license file one we can use?
   6. (sometimes) Are there a lot of open issues?
3. Make a selection and start coding

This list is missing a lot of requirements, and many times I've instead ended up building our own input library to meet them.

A deeper requirements check

I've worked on business applications with free off-the-shelf components, paid libraries, and custom. This is a more extended list of questions I consider (and if you have more, I'd love to add them).

Questions before starting the search

Use these questions to create specific requirements to help selection or during prototyping.

These are up front questions that require me to think more deeply about how the application will work and be validated. They should generate a more refined set of questions or points to validate.

Additional requirements to validate

Once I have the questions above, there's some more standard ones to consider as well.

This is a much better start. I suspect there's a few more you could think of from your own experience, too.

Creating custom inputs

I work primarily in the B2B space, which means a lot of applications that feature data entry.

Data entry is already fraught with error, so it's important to give the user every advantage we can, including consistent behavior and clear messaging. Our users range from folks on the first day of their new career to experienced power users, who know exactly how many tabs it takes to get to every box on the screen.

Not like this: Unexpected hijack of tab focus and sudden inverse behavior if you mis-type

Off the shelf components

Off the shelf components are attractive because they support a wide set of behavior ("we might need it one day") and because they have a cheap up front cost.

This is great for rapid prototyping to test ideas with real users, not so great when the quirks of the libraries end up shaping our back-end architecture or adding an overhead to every change. Or don't fix an issue after we've built half of our application around them, forcing us to fork and then maintain a library.

...And then we use one of those 100 "we might need it one day" features and find out it had a bug too. Which we now have to patch into our fork from a change made 6 months later on the official package, which has since had 50 other bug fixes. And there goes all the cost savings just to keep an "ok" solution working.

Designing Custom Inputs

I've built custom inputs for a variety of languages, most recently React and Svelte. While I don't have a one size fits all model, I do have some base principles I tend to follow each time.

Custom input requirements

To take this farther, in the most recent application I supported collaborative editing. We could both have a budget open on our own browsers (or one user have several tabs open), be editing different expense or revenue lines, and see each other's changes pop in in real time or see charts update as someone edits details.

Data flow design

How we manage state and applying behavior to that state is really important. From an architecture perspective, we need to determine what happens with invalid values, how values are scaled or formatted/unformatted, and how much of this is exposed to the rest of our codebase.

Inputs and data pipeline between UI and back-end models/logic

My preferences are:

1. Treat the UI as an API to the user: dirty data can come in, but it doesn't pass through to the business logic
2. Capture intended values, not typing: if you intend to enter $1,234.56, the experience will fee broken if I apply each keypress to downstream calculations and show totals or results for 1, 12, 123, etc. as you type
   • This one is more important than some developers realize. In a vacuum, updating values for key presses feels fast and interactive and clearly that's a better experience. Except there's a lot of cases where this doesn't match the actual domain, so it actually feels broken and creates doubt about how well we truly understand the customer need.
3. Preserve the rest of the screen: if dirty/partial input can't come through, then I don't have to worry about sub-totals going wonky
4. Always provide a way back, they should always be able to revert if they start typing in the wrong field

The input pipeline looks like:

1. Raw values can be entered, but are only evaluated when the user's intent is captured (full value for current, as they type of text)
2. Try to parse the value, proceed no further if the type is invalid
3. Scale the raw value from the visual scale to the real underlying value ($1MM becomes 1000000, 10% becomes .1)
4. Perform validation on the value, proceed no further if the value is invalid
5. Apply the update: update the binding or surface an event, depending on your architecture and whether your using mutable reactive props or immutable, event-driven updates

The output pipeline looks like:

1. A new value is applied (from input pipeline or prop update)
2. Scale the value, (1000000 becomes 1, .1 becomes 10)
3. Format the value (1 becomes $1MM, 10 becomes 10%)

You can see earlier implementation in a 2016 knockoutjs validation post and the companion post on testing validation.

So let's get to some code.

Coding a Custom Input, Svelte

This is a custom input using Svelte. It is one of several that follow the patterns above.

The broad strokes:

• It is a CurrencyInput for US Dollars
• This is for US locale, so the formatted value will include comma's for a thousands separator and a period for decimals
• This is USD, there are two decimal places, no more and no less
• The user must fully enter a value, we don't send individual key presses
• Edits from outside (new value received from another user) flow into the control and are displayed, but do not overwrite the value the current user is typing if they are mid-edit
• I could bind to the values, but I have a CRDT event pipeline behind the scenes so I want update events, not direct update of the bound prop
• Only re-format when the user is done
• I have built validation in:
  • The raw value must be valid before being sent as an update event
  • There will be minimum and maximum valid values: these also must be formatted for pretty error messages
  • When invalid, we lock the focus to the input (using a 1ms delayed focus due to browser event handling differences)

Usage looks like this:

<CurrencyInput
    value={expense.monthlyAmount}
    aria-label="Monthly amount"
    on:change={({ detail }) => {
        expense.monthlyAmount = detail.value;
        recalculateForecast();
    }} />

This is an example, it's been extracted from a much larger project with more polished brand styling and less inline event handling.

Reverting an invalid value and allowing (and correcting) currency signs and separators

Clearly tab and typing works as you would expect, and the temporarily styled validation error pops up with formatted validation values and the underlying valid value. Escape works as expected to reset to last valid value. While I'm typing a new value in, it shows the symbols I'm typing, even if it has to correct them when I'm done.

The underlying component looks like this:

<script lang="ts">
  import { createEventDispatcher } from "svelte";
  import { getCurrencyHelper } from "./currencyHelper";
  import ValidationPopup from "./ValidationPopup.svelte";

  // inputs
  export let disabled: boolean = false;
  export let min: number = 0;
  export let max: number = 100000000;
  export let id: string | undefined = undefined;
  export let value: number = 0.0;
  const ariaLabel: string | null = $$props["aria-label"];

  // -- prep for currency operations
  const locale = "en-US";
  const currency = "USD";
  const decimalScale = 2;
  const helper = getCurrencyHelper(locale, currency, decimalScale);
  // --

  // outgoing events
  const DEBOUNCE_LIMIT = 100; // ms
  const dispatch = createEventDispatcher();

  // validation + format methods
  function validateValue(parsedValue: number) {
    return !isNaN(parsedValue) && parsedValue >= min && parsedValue <= max;
  }

  function formatValue(value: number) {
    return helper.formatValue(value).replace("$", "");
  }

  // manage 3 values: the bound prop `value`, the validated `internalValue`, 
  //                  the formatted `visibleValue`
  let internalValue = value;
  let visibleValue = formatValue(value);
  //  - separating value from internalValue helps us detect incoming updates
  $: {
    if (internalValue !== value) {
      internalValue = value;
      visibleValue = formatValue(value);
    }
  }

  // prep for validation
  let isValid = true;
  let formattedMin = helper.formatValue(min);
  let formattedMax = helper.formatValue(max);

  // user interactions

  // - reset the typed value to the bound prop when they hit "Escape"
  function filterKeyDown(e: KeyboardEvent) {
    if (e.key === "Escape") {
      internalValue = value;
      visibleValue = formatValue(value);
      isValid = validateValue(value);
    } else if (!e.metaKey && !e.ctrlKey && !e.altKey && !helper.allowedCharacters.has(e.key)) {
      // prevent default events for keys that are relevant to this input, but allow
      //    other keys to do what they normally would 
      e.preventDefault();
    }
  }

  // - attempt to parse + validate new raw values once they are completely 
  //   entered: "blur" event
  function handleFocusOut(e: any) {
    const rawValue = e.target.value;
    const parsedValue = helper.parseValue(rawValue);
    if (!validateValue(parsedValue)) {
      e.stopPropagation();
      isValid = false;
      refocusWithDebounce(e.target);
      visibleValue = e.target.value;
      dispatch("validation", { isValid });
      return;
    }

    // may be unnecessary - if we exclude this it requires full round-trip 
    //  from bound value to display fresh formatting
    isValid = true;
    visibleValue = formatValue(parsedValue);
    // forced update in case the underlying values haven't changed, don't rely 
    //  on reactive update
    e.target.value = visibleValue;
    dispatch("validation", { isValid });
    if (parsedValue != value) {
      dispatch("change", { value: parsedValue, formattedValue: visibleValue });
    }
  }

  let lastFocusTime = 0;
  function refocusWithDebounce(target: any) {
    const time = new Date().getTime();
    if (time - lastFocusTime > DEBOUNCE_LIMIT) {
      lastFocusTime - time;
      setTimeout(() => target.focus(), 1);
    }
  }
</script>

<style lang="scss">
  @import "../../styles/_variables.scss";

  /* ... */
</style>

<div class="gdb-input gdb-faux-input" class:isInvalid={!isValid} class:disabled>
  <span class="gdb-input-symbol">$</span>
  <input
    type="text"
    {id}
    value={visibleValue}
    on:keydown={filterKeyDown}
    on:focusout={handleFocusOut}
    role="textbox"
    {disabled}
    tabIndex={disabled ? -1 : 0}
    aria-label={ariaLabel} />
  <ValidationPopup {isValid}>
    <span slot="message">
      Enter a value between <b>{formattedMin}</b> - <b>{formattedMax}</b>.
    </span>
    <span slot="note">
      or press "Esc" to return to {helper.formatValue(internalValue)}
    </span>
  </ValidationPopup>
</div>

For those not familiar with svelte:

• Any section prefixed with a $ is re-evaluated reactively when a referenced value changes
• The HTML section updates reactively to changes to any values referenced
• slots are containers that the caller can provide values for (like React/Angular/etc), or default to the values above when not provided (allowing us to create more custom validation messaging in either place as needed)

This doesn't meet the requirements yet, however

Ignoring the temporary styling, there's two additional requirements that aren't met:

1. If you and I are typing at the same time, currently your value could replace mine (we need one more value buffer between the raw input value and internalValue, or an incoming value will update in the input even if you're mid-edit)
2. Detecting a user done editing: blur/focusout is one way, but a timer could also be used to detect a long pause and assume the user is done which might be a better indication the user's intent is complete (or worse, I go back and forth on this)

The last part of this is adding tests (or in this case, it was the first part).

Testing

I'm using Svelte Testing Library, which offers a bonus that the interactions I'm performing at this level also ensure the targeting and readability I want when I test with UI testing tools like Playwright or Selenium.

An individual test is quick and easy to write:

it("Parses and formats a raw entered value that has extra characters", async () => {
    const { getByRole } = render(CurrencyInput);

    const currencyInput = getByRole('textbox') as HTMLInputElement;
    currencyInput.value = "$$1,2,3,4.56";
    await fireEvent.focusOut(currencyInput);
    await fireEvent.blur(currencyInput);

    expect(currencyInput.value).toBe("1,234.56");
});

A downside of this method is I have to know how to fire the appropriate events, but this is still much better than some of the limitations we've had with earlier component testing libraries (like enzyme in React once you started nesting components and wanting to read or interact with those nested components).

Then, on top of this, I run WallabyJS, which means I can quickly write a new test case, see it fail, add the logic, and on we go. I don't TDD all the time, but input and low-level component design tends to be a good place to design with that external API in mind first.

Wrapping Up

My personal opinion is that if data input and manipulation is a core part of your user experience, you should be designing your own input library to make that rock solid. By definition, third party libraries are trying to build for far more generic capabilities, with broader feature sets and more capabilities that you won't need (adding bugs, overhead, and lower prioritization to bugs you need fixed).

I've also found accessibility and testability to be gaps in almost all of them. And if you need a themeable UI, you're probably going to invest in building it yourself anyway.

Each UI library or framework will have it's own peculiarities, and you will have to learn them, but I think it's absolutely worth it. Knowing the ins and outs of input eventing in different browsers is valuable. Knowing how to work with controlled and uncontrolled React components is valuable. Thinking about what that update pipeline needs to be in your application (and not letting a 3rd party component dictate your architecture) leaves you options that can be extremely impactful.