Case Sensitivity with `localeCompare` in JavaScript

Corey Ward — Fri, 22 Sep 2023 20:03:19 +0000

I recently ran into a bug using code like the following:

someArray.sort((a, b) => a.name.localeCompare(b.name))

At a glance this seems fine—localCompare enjoys fantastic browser support, and as the name suggests, it isn’t English-centric. However, this is still the web we’re building for, and the familiar gotcha of inconsistent behavior amongst browsers is lurking here. This can lead to hard-to-debug inconsistencies and bugs.

Most browsers—including Chrome, Edge, and Firefox—and Node treat localeCompare as case-insensitive by default, treating an uppercase “A” as the same as a lowercase “a”. Safari, however, does something different.

Safari uses a variant of case-sensitive sorting, but not in the usual ASCII order where “Z” sorts above “a”. Instead Safari sorts lowercase letters above their uppercase companions, but in alphabetical order otherwise, like “aAbBcC”. In many cases this is fine—sorting based on the user’s locale is not only acceptable, it’s preferable. But as you may suspect given the title, that’s not always true.

In scenarios where data is expected to match the order from a server, such as when sorting properties before hashing for verification or as a checksum, or when hydrating server-side rendered React, this behavior becomes troublesome. In these cases, consistent behavior across environments is critical to prevent bugs. Thankfully, this can be achieved by specifying a few additional options to localeCompare:

a.name.localeCompare(b.name, "en", { sensitivity: "base" })

First, we’re specifying an expected locale. This ensures the items are compared in the same locale server-side and client-side. In a localized app, this value can be localized as well, just be sure to use the same value in both environments.

The second change, adding sensitivity: "base", tells browsers to use the base character (think lowercase) for comparison (MDN), effectively making the comparison case-insensitive. This results in consistent sorting behavior across Node and all common browsers (including IE11). 🎉

Use Neon.tech Postgres as a Segment Data Warehouse

Corey Ward — Fri, 22 Sep 2023 16:50:48 +0000

Note: At the time I wrote this, Neon had very different pricing that allowed you to pay as you go for storage and compute, all starting at $0. They have since switched to a pricing model that does not allow you to scale storage without paying $69/mo (base price). They also have a terrible track record for uptime. I have since switched to Supabase for scalable Postgres hosting, and I recommend anybody considering Neon look at alternatives instead.

Segment allows users to connect a Postgres database as a data warehouse. Officially they only support Heroku, who seems to be on its way out, and AWS RedShift, which has rather complex pricing and a more limited feature set than a standard Postgres install. Unofficially, though, the service works with any standard, modern Postgres install.

Neon is a serverless-oriented provider of hosted, managed Postgres databases that scale automatically based on usage. It's convenient, and because you don't have to commit to a storage tier and worry about complicated processes for upgrading to larger instances, it winds up priced in a compelling manner.

Connecting Segment to Neon is a mostly straightforward affair, but because Segment doesn't support SNI-based TLS on Postgres connections, Neon needs a bit of additional information to know which endpoint is being connected to. Usually it's sufficient to add this information to the connection string, but Segment insists on having all of the values broken up and fails if you modify the hostname to include a path or query string. Thankfully, Neon has a multitude of ways to specify the endpoint, including one that works with Postgres.

Connecting to Neon PG from Segment

In the Segment interface, create a new Postgres data warehouse. Be sure to choose "Destination" connection and not the "Source" version. Choose a source as desired, and then you'll get brought to the connection details screen.

From here you'll enter most of the values copied from your Neon connection string, but when you get to the password field you'll need to make a change. Instead of entering the password as-is, you'll prefix it with a configuration flag specifying the endpoint, like so:

endpoint=<endpoint-id>;<password>

The endpoint ID is the first-listed (leftmost) subdomain in the hostname. For example, if your full hostname is ep-fun-coding-94135731.us-east-2.aws.neon.tech, the endpoint ID is ep-fun-coding-94135731. If your password is abcd1234, your final value for the password-field would be:

endpoint=endpoint=ep-fun-coding-94135731;abcd1234

Plug that in and you'll get something like this

Click "Connect" and you should be all set!

DEV Community: Corey Ward

Case Sensitivity with `localeCompare` in JavaScript

Use Neon.tech Postgres as a Segment Data Warehouse

Connecting to Neon PG from Segment