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
export const is a named export that exports a const declaration or declarations. To emphasize: what matters here is the export keyword as const is used to declare a const declaration or declarations. export may also be applied to other declarations such as class or function declarations.
TypeScript supports export = to model the traditional CommonJS and AMD workflow. The export = syntax specifies a single object that is exported from the module. This can be a class, interface, namespace, function, or enum.
Use named exports to export a function in TypeScript, e.g. export function sum() {} . The exported function can be imported by using a named import as import {sum} from './another-file' . You can use as many named exports as necessary in a single file.
Use named exports to export multiple functions in TypeScript, e.g. export function A() {} and export function B() {} . The exported functions can be imported by using a named import as import {A, B} from './another-file' . You can have as many named exports as necessary in a single file.
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With