Javascript/Typescript: what's the difference between exporting single functions or a const class?

Question

I'm developing a web application in VueJs, Typescript and WebPack and I'm a bit confused about how to manage/split groups of functions (utilities and services).

I saw in various project in GitHub that some functions are declared and exported directly from the file ex:

utilities.ts

export function Sum(a:number, b:number):number{
    return a+b;
}

this can be used with an import:

import {Sum} from "./utilities.ts"

let result = Sum(5,6);

Another common solution is to declare a const class:

otherUtilities.ts

export const OtherUtilities = {
    Sum(a:number, b:number) : number => {
        return a+b;
    },
    
    Hello() : string => {
        return "Hello";
    }
}

and import as:

import {OtherUtilities} from "./otherUtilities.ts"

let result = OtherUtilities.Sum(5,6);

What are the differences?

In the past, there was the Name Conflict issue with JS but now with the export/import technique via Loaders, this issue should be outdated, right?

Thank you

"In the past, there was the Name Conflict issue with JS" - can you please explain ? — Ritwick Dey, Mar 07 '19 at 09:37
I was thinking about global variables in a site: if you use Jquery and your library declare itself with a '$' you have a conflict. To mitigate this problem you can wrap your functions into a variable that should be unique. Example: var MyCompany = { StrUtilities : { $()... and you use it like MyCompany.StrUtilities.$(...) — IGionny, Mar 07 '19 at 10:22
There is no such thing as a "const class". What you are referring to is simply an Object with methods attached to it. — Patrick Hollweck, Aug 19 '21 at 13:31
Does this answer your question? [Class with static methods vs exported functions typescript](https://stackoverflow.com/questions/55149221/class-with-static-methods-vs-exported-functions-typescript) — Michael Freidgeim, Sep 05 '21 at 01:16

score 13 · Accepted Answer · edited Apr 21 '20 at 01:13

This object:

export const OtherUtilities = {
    Sum(a:number, b:number) : number => {
        return a+b;
    },

    Hello() : string => {
        return "Hello";
    }
}

Contains two completely unrelated functions. They don't need to share a this context, don't know each other, and could perfectly be exported as two separated functions, even in two separate modules. They can belong to the same object, but there is no strong reason to do that.

On the other hand, if you export them as separate entities:

export function sum()...
export function hello()...

They are tree shakeable. If your application happens to only import Hello(), them Sum can be dropped from the bundle.

Now, with the second strategy, you're more likely to get naming collisions. You can prevent them using the as keyword:

 import {Sum} from 'one';
 import {Sum as myCustomSum} from 'two';

Apart from the tree shaking, I don't think there's much differences between one style or the other. You can export anything with ECMAScript modules, would it be functions, strings, numbers or any other kind of primitives, arrays or objects. It's pretty much up to you and the code conventions of your team.

Some libraries used to export independent functions belonging to a big utility object, but then changed the style and switched to independent named exports, precisely to enable tree shaking (and sometimes, just independent projects do that, like lodash-es).

…and if you want to use `OtherUtilities.Sum()` in the code, you can still do `import * as OtherUtilities from '…';`. — Bergi, Mar 07 '19 at 11:46

score -1 · Answer 2 · answered Apr 07 '20 at 16:27

-1

using functions:

export function sum(a: number, b: number): number {
    return a + b;
}

using method :

export class Math {
    static sum(a: number, b: number): number {
        return a + b;
    }
}

answered Apr 07 '20 at 16:27

Trilok Singh

1,227
12
10

Javascript/Typescript: what's the difference between exporting single functions or a const class?

2 Answers2