I’ve got three posts in my brain backlog now about more complex software concepts showing up in UI work. Here’s the first!

I’ve been waiting for years, thumbing a bitwise operator curiously. Finally the opportunity presented itself the other day.

Writing UI, most of the time the basic comparison and logical operators of JavaScript give us the power and control we need to deliver product requirements. Equal, not equal, AND, OR, NOT, etc.. But then there’s that arcane set of bitwise comparison operators. These special boolean operators give us expressiveness for more complex comparison scenarios. Their weirdness stems from the fact they do comparisons at the binary integral level. They coerce the values to bits first, far from view.

Take XOR – “exclusive OR”. In JavaScript XOR will return 1 when the output of either side of the operator is different, else 0. Similar to a boolean return, we can easily pass around the result of a bitwise operator as a predicate.

As it turns out, this happens to be the very logic we need for testing existence between two dependent form fields on the frontend.

At Eventbrite, the UI library has graphical pickers for both date and time fields that we use in Event creation workflows. Our designs typically place these fields next to each other and make them required. We provide sensible defaults, but event creators can freely modify the values, unpredictably, even nulling them out. For example, it’s possible for the user to leave one field blank. We want to give event creator immediate feedback before they go on to other tasks on the page. If they put the form in this state, we run a validation on blur. And we can do it using XOR logic!

Nevertheless, for checking existence, we don’t want to bitwise compare the two sides of the expression directly. These fields liberally capture data as strings (versus ints, datetime, etc…). To make the comparison reliable, we first cast each side to boolean values with using bangs for brevity. Then we wrap up the expression in a composable function. The result is a very concise one-liner:

const isOneTruthyAndTheOtherNot = (a, b) => !a ^ !b;

Which might be passed around in a hypothetical React event handler like:

dateTimeValidator: (dateValue, timeValue) => {
    const hasEmptyField = isOneTruthyAndTheOtherNot(dateValue, timeValue);
    const error = hasEmptyField ? FORM_ERRORS('dateTimeField') : null;

    this.setState({
        dateTimeFieldError: error
    }

    this.props.onError(error)
}

This could be written in a couple ways without the more arcane XOR:

... = ( foo && !bar ) || ( !foo && bar );
... = foo ? !bar : bar

But those expressions are tough to mentally load on glance. On the other hand, the bitwise operators are clever, but the single operator is a standard interface. Even a less experienced engineer can quickly reference the MDN docs which are crystal clear about how the XOR algorithm works:

“Performs the XOR operation on each pair of bits. a XOR b yields 1 if a and b are different”

The docs will also introduce you to the algorithmic decision table for the operator logic, which is a great learning device for engineers of all levels.

|  a  |  b  | a XOR b |
| :-: | :-: | :-----: |
|  0  |  0  |    0    |
|  0  |  1  |    1    |
|  1  |  0  |    1    |
|  1  |  1  |    0    |

What always makes this sort of exposé interesting to me is that we get a chance to trouble the early-web understanding of UI as document structure and style. There’s still too much emotional labor educating the web dev community about complexity throughout all layers of what’s becoming an increasingly mushy layer cake stack. Computer science in form logic. Like blended, bleeding, fluid, transitional. Not the pejorative gross, unfit, or unstable.