DEV Community: Suiko

JavaScript Trick: Guessing Users' Country Calling Codes by Time Zone

Suiko — Mon, 20 Mar 2023 18:58:48 +0000

As developers, we often need to determine a user's location to provide better services. One key piece of information that can be useful is the user's country calling code - the prefix used when dialing international phone numbers. One efficient and reliable way to guess users' country calling codes in JavaScript is based on their time zone. You can explore the demo on this website.

Why Guessing Users' Country Calling Codes Matters

Guessing users' country calling codes can be helpful for several reasons:

Formatting Phone Numbers: Automatically formatting phone numbers based on the user's location can enhance user experience by adding the appropriate country calling code and formatting the number itself according to local conventions.
Selecting Dialing Prefixes: Using the correct dialing prefix when making international calls can be crucial. By guessing the user's country calling code, you can select the appropriate prefix automatically and make the call process smoother for the user.
Geo-Targeting: You may want to show specific content or features based on the user's location. Guessing their country calling code can help make more accurate geo-targeting decisions.

Introducing a New Solution: Guessing Based on Time Zone

I've just released a library on NPM called guess-calling-code, offering a streamlined method for guessing users' country calling codes in JavaScript based on their time zone. This library leverages the Intl.DateTimeFormat API to obtain the user's time zone, which it then cross-references with a list of time zone-to-country phone code mappings.

Usage

Here's an example usage of guess-calling-code:

import guessCallingCode from 'guess-calling-code';

const callingCode = guessCallingCode();

if (callingCode) {
  console.log(`User's country calling code is ${callingCode}`);
} else {
  console.log('Unable to determine user\'s country calling code');
}

You see, it's easy to use.

How it works

First, here's a function to retrieve the user's time zone city using the Intl.DateTimeFormat API:

function getUserTimeZoneCity(): string | undefined {
  try {
    const userTimezone = Intl.DateTimeFormat().resolvedOptions().timeZone;
    if (!userTimezone) return;
    const timezoneArr = userTimezone.split("/");
    const result = timezoneArr[timezoneArr.length - 1];
    return result;
  } catch (error) {
    return;
  }
}

This function returns the user's time zone city string like "Montreal" or undefined if the runtime doesn't support the Intl namespace.

Next, we define our main function, guessCallingCode, which calls getUserTimeZoneCity and cross-references the resulting city name with our pre-populated JSON object of known city-to-calling-code mappings:

function guessCallingCode(): string | undefined {
  const timezoneCity = getUserTimeZoneCity();
  if (!timezoneCity) return;
  const callingCode = timezoneCityToCallingCodeObj[timezoneCity];
  return callingCode;
}

With just these two functions, you can easily and accurately estimate a user's country calling code.

If you're interested in how the time zone city to calling code JSON is generated, check out this post which introduces a way to map time zone cities to countries. I based my code on this approach to map time zone cities to country phone codes.

Advantages of Guessing Based on Time Zone

Why choose to guess users' country calling codes based on their time zone? Here are some of the key advantages:

Client-Side Solution: Unlike server-side IP address lookups, guessing based on time zone can be done entirely client-side, reducing latency and freeing up server resources.
Lightweight: The library published on npm is small (< 15 KB), making it easy to integrate into a wide range of projects.
High-Level of Accuracy: Most devices have accurate time zone settings, making this approach highly accurate and reliable. Additionally, it is more accurate than IP-based methods that can be thrown off by VPNs or proxies.

In addition to these advantages, since Intl is an ECMAScript Internationalization API, you can use it in both modern browsers and node.js.

Conclusion

Guessing users' country calling codes based on their time zone can be a valuable addition to any developer's toolkit. Whether you're building a messaging app, ride-sharing service, or any other application involving phone numbers, consider using guess-calling-code.

Links related to the topics covered:

Intl.DateTimeFormat API: MDN Web Docs
guess-calling-code library: npm, showcase
Mapping time zone cities to countries: Techighness post
Example usage of guess-calling-code: GitHub repository

I hope this article has provided a helpful explanation on how to determine country calling codes using JavaScript and the advantages of utilizing time zones as a reference. If you found guess-calling-code helpful, kindly consider giving it a star on GitHub Repo❤️. Please don't hesitate to share any feedback or questions in the comments section below. Your engagement is greatly appreciated!

A utility type for converting union to set in TypeScript

Suiko — Sat, 04 Feb 2023 09:31:00 +0000

Motivation

Assume you are working on a Todo app.

This app uses an HTTP API to retrieve all of the to-do items. You and your back-end colleagues agree on a data type for to-do：

type Todo = {
  id: number;
  title: string;
  description: string;
  /**
   * 0 means active, 1 means completed
   */
  status: 0 | 1;
};

This Todo app contains a select component for filtering out active/completed items, and you could build the following data structure to represent all of the possible options:

const statusFilterOptions = [
  {
    value: 0,
    label: "active",
  },
  {
    value: 1,
    label: "completed",
  },
];

You may define a type for this data structure to avoid a coworker or yourself from accidentally outputting a bug while refactoring this code later：

type Option = {
  value: Todo["status"];
  label: string;
};

const statusFilterOptions: Option[] = [
  {
    value: 0,
    label: "active",
  },
  {
    value: 1,
    label: "completed",
  },
];

In general, if your team is simply using Typescript, this is sufficient. However, if we want to be more specific about the type of statusFilterOptions, we may go much farther here. The following examples of statusFilterOptions, while satisfying the Option type, will cause bugs in the select component used to filter out incomplete/completed items in a production environment:

// some value in options
const statusFilterOptions: Option[] = [
  {
    value: 1,
    label: "active",
  },
  {
    value: 1,
    label: "completed",
  },
];

// missing one option
const statusFilterOptions: Option[] = [
  {
    value: 1,
    label: "active",
  },
];

// option is overwritten by one
const statusFilterOptions: Option[] = [
  {
    value: 0,
    label: "active",
  },
  {
    value: 1,
    label: "completed",
  },
  {
    value: 2,
    label: "completed",
  },
];

Not only to eliminate the above bug cases, but consider a real-world business scenario in which the product may change frequently, and the status of todo may become 0, 1 and 2 later on. To prevent the situation where only the Todo type is modified and the filter options are not modified at the same time, we can write a type that can be widely used in such scenarios.

Coding

Consider our type's input and output first. We expect the input type to be a set like 0 | 1 or male | female, and the expected output type should be an array containing all the elements of the set precisely, one cannot be more, one cannot be less 🙅, and the order of the array elements is adjustable. It is easy to conclude that what we need is a type that converts union to set. The following is the UnionToSet code.

type UnionToSet<
  U extends string | number | symbol,
  R extends (string | number | symbol)[] = []
> = {
  [S in U]: Exclude<U, S> extends never
    ? [...R, S]
    : UnionToSet<Exclude<U, S>, [...R, S]>;
}[U];

The above code implements the conversion by recursively traversing U. The three following points should be noticed at ⚠️：

Uses the heavyweight features provided by TypeScript version 4.0: Variadic Tuple Types。Therefore, it can only be used in TypeScript 4.0 and above.
Based on recursion. Although TypeScript 4.5 is optimized for tail recursion，Although TypeScript 4.5 is optimized for tail recursion, the UnionToSet cannot be converted to tail recursion mode, so please do not use it when the collection is too large.
JavaScript Object key type limitation. Because of the JavaScript object key limitation, TypeScript is limited to the type of U in '[S in U]' must inherit from'string | numebr | symbol', therefore a union such as 'true | false' cannot utilize this type. Of course, because the Boolean type has only two values, Even if you make a typo on True or False, your IDE will tell you, so it is not essential to restrict the type precisely.

Here we can do a small optimization, in the above code, U inherits from string | number, R inherits from string | number, so we can abstract this type and mask U and R to the user：

type UnionToSetHelper<
  T extends keyof any,
  U extends T = T,
  R extends T[] = []
> = {
  [S in U]: Exclude<U, S> extends never
    ? [...R, S]
    : UnionToSetHelper<T, Exclude<U, S>, [...R, S]>;
}[U];

export type UnionToSet<T extends keyof any> = UnionToSetHelper<T>;

The following are examples of 'UnionToSet' test cases:

const a: UnionToSet<0 | 1> = [0, 1]; // ✅
const a: UnionToSet<0 | 1> = [1, 0]; // ✅
const b: UnionToSet<0 | 1> = [0, 1, 2]; // ❎
const c: UnionToSet<0 | 1> = [0]; // ❎
const d: UnionToSet<0 | 1> = [1, 1]; // ❎

Based on the UnionToSet type we built, we can simply code a Options type that is strongly associated with real-world business:：

type Option<T extends keyof any> = {
  value: T;
  label: string;
};

type OptionsHelper<
  T extends keyof any,
  U extends T = T,
  R extends Option<T>[] = []
> = {
  [S in U]: Exclude<U, S> extends never
    ? [...R, Option<S>]
    : OptionsHelper<T, Exclude<U, S>, [...R, Option<S>]>;
}[U];

type Options<T extends keyof any> = OptionsHelper<T>;

The following is the Todo demo in this article; you may attempt to edit the 'Todo' type in'src/App.tsx' after forking:

Bonus

This article concentrates on the situation of 'union to set', and it's logical to question if 'union' can be converted to 'tuple'(sorted set).
You can jump to this issue to see what people are talking about. This question is also available in type-challenge.

In the end

I'd love to hear your feedback and suggestions❤️, you can find this post on my website.