# Mathematics of the front “under one roof”

“Yes, what are you on[фиг] optimizer? fuck, tfu.”

## Problem

I came to a new project where three mathematical libraries were connected. The code base absorbed the experience of several development teams and represented a typical legacy where it is not always possible to justify a particular decision. Having reached optimization in the backlog, I began to sort out options for how this could be solved. As a result of my reflections, I came to the conclusion that I want to keep all the existing libraries, but remove the difference in the API from my eyes. I want to configure the “math engine” on the fly at one point (without getting into, directly, the client code itself).

## Solution

Syntax of mathematical expressions based on arrays (called nemathode and created a separate page for it with all the information that will help you get involved in this mechanism). I wanted it to be as close as possible to most popular languages, but primarily to JavaScript.

That is, nothing much changes:

parentheses are changed to square brackets;

operators (constants, function names) are enclosed in quotation marks;

and the configuration happens at one point (which we will get to shortly).

With this thing, I can now:

continue to use a bunch of math libraries and configure them all at one point hiding API details

add new methods, operators, constants and choose convenient naming;

calibrate the accuracy and speed of calculations on the fly (correct current implementations, replace mathematical constants with more suitable values).

## Examples of using

**Binary operators**

**Functions**

**Mathematical constants**

**Nested expressions**

## Configuration example

More library customization examples can be found here

**mathConstants**

Literally, mathematical constants

**functions**

Implementation set

**toInputType**

It seems redundant, but not everyone uses pure JS functionality. There are a number of libraries where the intermediate type in calculations is not a number (bignumber.js, decimal.js). Thus, we can set up this handler as in the example below.

**toOutputType**

The opposite of toInputType. See example below

**binary Operators**

**API – standard**

**API – with love ❤️**

## Afterword

**inspired**

question on stackoverflow

Several tasks on codewars (can’t remember the name)

math.js library and its calculation engine

**In the future (if the solution is useful not only to me)**

Full TS coverage (so that there is an autocomplete for operators when writing expressions)

Unary operators (still doubt about their necessity. Need your opinion)

Handling Function Arguments

Overcome limitations associated with return types (number, boolean etc)

**And finally**

If you have questions, suggestions, wishes, criticism – I will be glad to hear feedback in any form. Link to the website with all the necessary information.