8

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

4
  • "In the past, there was the Name Conflict issue with JS" - can you please explain ? Commented Mar 7, 2019 at 9: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.$(...) Commented Mar 7, 2019 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. Commented Aug 19, 2021 at 13:31
  • Does this answer your question? Class with static methods vs exported functions typescript Commented Sep 5, 2021 at 1:16

2 Answers 2

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).

Sign up to request clarification or add additional context in comments.

1 Comment

…and if you want to use OtherUtilities.Sum() in the code, you can still do import * as OtherUtilities from '…';.
-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;
    }
}

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.