# Formatting

Opinions on code and value formatting.

# Formatting code

# Prettier

To alleviate a bombardment of tedious formatting related Merge Request comments, we utilize a tool called Prettier to handle automatic formatting. Your text editor of choice should have support for this, and can even be configured to auto-format on save, to ensure you are always consistent.

Our default Prettier configuration
{
  "semi": true,
  "trailingComma": "all",
  "singleQuote": true,
  "arrowParens": "always",
  "printWidth": 100,
  "useTabs": true,
  "endOfLine": "auto"
}

# Husky and Lint Staged

We utilize a pre-commit hook, facilitated by husky and lint-staged to run Linting checks with eslint on all staged files before a new commit is made.

# Imports

We prefer to organize our import statements for consistency when reading and editing imports. The order of specific named variables being imported from a file does not matter, but the order of the files does. Imports should be in this order, with line breaks between each section:

  • External packages
  • Internal files that are not the same directory
  • Internal files are are in the same directory
Example import order
import React, { useState } from "react";
import { axios } from "axios";
import { PrimaryButton } from "mfb-vinyl";

import { MyComponent } from "../MyComponent";
import { MyPageComponent } from "../../pages/users/MyPageComponent";
import { formatMoney } from "../../lib/utils/formatMoney";

import styles from "./styles.module.css";

# Formatting data

# Primitive data types

When converting a string into a number, prefer using Number() instead of parseInt(). When converting a number into a string, prefer .toString() over string templating (`${someNumberVariable}`), and avoid using String().

Don't use Boolean(). Also, often we use !! to indicate that we're only checking the truthiness/falsiness of a value even if technically it'd execute correctly without that.

# Money

In cases where you need to convert a number into a formatted currency string, useNumberFormatter() from react-aria is our preferred tool. It calls the browser's built-in Intl.NumberFormat object to handle all the intricacies of displaying currency in the current locale.

When sending currency values to and from the server, these should be sent as numbers, not strings. Keep currency values as numbers throughout the app and only convert them to a formatted currency where the user will see or interact with them. If you need to represent a null value for currency, use NaN.

# Date and time

Time is notoriously hard to work with in programming, especially when dealing with time zones. To make everything consistent, the server should provide (and be provided with) times in UTC, using standard ISO formatting. When the frontend displays a time, it should be converted to the user's local time for display; if sending a time back to the server, it should be converted to UTC.

react-aria provides another helpful utility for formatting times and dates: useDateFormatter(). Much like a date-based version of useNumberFormatter, it calls the browser's built-in Intl.DateTimeFormat object and handles the intricacies for us.