Skip to content

Project Structure

Jump to bottom
George Kamtziridis edited this page Oct 23, 2021 · 2 revisions

Project Structure

The project follows a very basic and intuitive structure. The source files are located in the /src folder where each subfolder is a distinct module. Currently, the structure looks like this:

locale-to-number.js    
│
└───src
│   │
│   └───core
│   │    
│   └───create-template-string
│   │
│   └───get-number
│   │
│   └───locale-mapper.js

Core

The core module contains the basic functionality that is shared across the application. The module consists of 2 files:

  1. core.js: contains the needed functionality for handling numerical representation in string formats.
  2. core.spec.js: contains the unit-tests for the provided functionality.

CreateTemplateString

This is a dummy module that can be used as a reference when creating a new module.

GetNumber

The getNumber module is the one that actually converts a string representation of a number to the actual decimal literal. The module consists of the main file, named get-number.js, and a specs folder where each locale is tested thoroughly in an isolated environment. The structure looks like this:

src  
│
└───get-number
│   │
│   └───specs
│   │    └───get-number.en.spec.js
│   │    │   ...    
│   │    └───test-case-generator.js
│   │    
│   └───get-number.js

The get-number.js file implement the main functionality of the package. However, this exact functionality needs to be tested for each locale separately. These tests are placed in the /specs folder following a self-explanatory naming convention: get-number.{locale}.js.

The test-case-generator.js file contains some utility functions that create dynamically test cases. As we've already mentioned, the locale-to-number.js aims to fulfil the need for converting numerical string representation to decimal literals which is not supported by Intl.NumberFormat. In other words, locale-to-number.js does the exact opposite of what Intl.NumberFormat class does via its format() function. So, we can utilize the already implemented functionality of Intl.NumberFormat to construct a huge number of configurable test cases.

Every spec file in this module makes use of the test-case-generator utilities. More precisely, in each locale spec file one must firstly test manually. Then, the developer must use the testCaseGenerator to create test cases for the given ranges:

  • Positive numbers (each range contains 1000 random numbers)
    • [0, 1]
    • [1, 100]
    • [100, 1,000]
    • [1,000, 10,000]
    • [10,000, 100,000]
    • [100,000, 1,000,000]
    • [1,000,000, 10,000,000]
    • [10,000,000, 100,000,000]
    • [100,000,000, 1,000,000,000]
    • [1,000,000,000, 10,000,000,000]
    • [10,000,000,000, 100,000,000,000]
    • [100,000,000,000, 1,000,000,000,000]
    • [1,000,000,000,000, 10,000,000,000,000]
    • [10,000,000,000,000, 100,000,000,000,000]
  • Negative numbers (each range contains 1000 random numbers)
    • [-1, 0]
    • [-100, -1]
    • [-1,000, -100]
    • [-10,000, -1,000]
    • [-100,000, -10,000]
    • [-1,000,000, -100,000]
    • [-10,000,000, -1,000,000]
    • [-100,000,000, -10,000,000]
    • [-1,000,000,000, -100,000,000]
    • [-10,000,000,000, -1,000,000,000]
    • [-100,000,000,000, -10,000,000,000]
    • [-1,000,000,000,000, -100,000,000,000]
    • [-10,000,000,000,000, -1,000,000,000,000]
    • [-100,000,000,000,000, -10,000,000,000,000]

LocaleMapper

Finally, the locale-mapper.js contains the mapping between the supported locale id, for instance en, and the thousands and decimal separators, for instance , and . respectively.

Clone this wiki locally