작품: https://code-art.pictures/
요즘에는 놀랄 수도 있지만 인터넷 트래픽은 여전히 많은 상황에서 문제가 되고 있습니다. 모바일 네트워크에는 데이터 요금제가 제한된 경우가 많고, 장치 배터리는 무한하지 않으며, 가장 중요한 것은 사이트 로드를 기다리는 동안 사용자의 관심이 제한된다는 것입니다. 이것이 바로 번들 크기가 여전히 중요한 이유입니다. 고려해야 할 7가지 팁은 다음과 같습니다.
2020년에는 지역 소셜 네트워크 홍보 앱을 운영하고 있었습니다. ES5를 타겟으로 한 전형적인 React TypeScript 웹팩 애플리케이션이었습니다. webpack 5가 출시되자 업그레이드를 하기로 결정했습니다. 모든 것이 순조롭게 진행되었습니다. 오류 분석과 사용자 피드백을 모니터링했는데 예상치 못한 일은 없었습니다. 일주일이 지나서야 우연히 내 번들에 화살표 기능이 포함되어 있다는 사실을 알게 되었습니다. 이는 새로운 웹팩 기능이었습니다.
다음은 ES5의 상태에 대한 훌륭한 기사입니다. 주요 내용:
더 훌륭하고 컴팩트한 코드를 작성할 수 있는 몇 가지 기능은 다음과 같습니다.
생성기는 중첩된 구조를 탐색하는 효율적인 방법입니다.
type TreeNode<T> = {
left?: TreeNode<T>
value: T
right?: TreeNode<T>
};
function* traverse<T>(root: TreeNode<T>): Generator<T> {
if (root.left) yield* traverse(root.left)
yield root.value
if (root.right) yield* traverse(root.right)
}
축소자는 이러한 필드가 내보낸 객체에서도 외부 용도로 사용될 수 없으며 이름을 자유롭게 줄일 수 있다는 것을 확실히 알고 있습니다.
출처
export class A {
#myFancyStateObject
}
번들
export class A{#t}
물론 TypeScript 비공개 필드에서는 작동하지 않습니다. tsc가 작업을 완료하면 해당 필드가 비공개라는 지식이 사라지기 때문입니다.
Promise.withResolvers() 또는 Map.groupBy()에 대해 들어보신 적이 있나요? 이 API는 이 글을 쓰는 시점에는 널리 사용 가능하지 않지만 곧 제공될 예정입니다. 지금 잠시 시간을 내어 익숙해지고 몇 년 후에 입양할 준비를 하세요.
수많은 블로그와 팟캐스트가 있지만 가장 좋은 '뉴스레터'는 TypeScript 저장소에 있는 새로운 .d.ts 파일입니다. 예를 들어 es2024.collection.d.ts를 열고 즐기세요 ?
반복되는 패턴이 보이시나요?
type TreeNode<T> = {
left?: TreeNode<T>
value: T
right?: TreeNode<T>
};
function* traverse<T>(root: TreeNode<T>): Generator<T> {
if (root.left) yield* traverse(root.left)
yield root.value
if (root.right) yield* traverse(root.right)
}
반복되는 코드는 번들 크기를 늘릴 뿐만 아니라 각 부분의 기능을 이해하기 어렵게 만듭니다. 이로 인해 개발자는 기존 유틸리티 기능을 식별하고 재사용하는 대신 새로운 코드를 작성하게 되어 번들을 더욱 비대하게 만듭니다.
이 주제에 관한 우수한 자료가 이미 풍부하므로 다시 설명하기보다는 마틴 파울러의 리팩토링이라는 고전을 추천합니다. 위와 같은 단순한 사례뿐만 아니라 결합 계층, 반복 디자인 등 복잡한 사례도 다루고 있습니다.
이제 작은 예를 개선해 보겠습니다. 클램프는 매개변수를 배열 인덱스 범위로 제한하는 데 자주 사용되는 것 같으므로 다음과 같은 단축키를 만들 수 있습니다.
export class A {
#myFancyStateObject
}
이 변경으로 인해 n은 현재 확인되지 않은 정수가 될 가능성이 있음이 분명해졌습니다. 또한 처리되지 않은 극단적인 경우인 빈 배열을 강조합니다. 이 작은 중복 제거를 통해 우리는 두 가지 잠재적인 버그도 발견했습니다.
이 말의 정확한 출처는 기억나지 않지만, 딱 맞는 것 같습니다.
오버엔지니어링은 자신이 갖고 있지 않은 문제를 해결하는 것입니다.
웹 개발 세계에서는 두 가지 주요 유형의 오버엔지니어링을 관찰했습니다.
이 코드를 고려해 보세요. 패딩은 4px의 배수이고 배경색은 파란색 음영입니다. 이는 아마도 우연이 아닐 것이며 만약 그렇다면 중복 가능성이 있음을 나타낼 수 있습니다. 하지만 일반 Button 구성 요소를 추출할 만큼 충분한 정보가 실제로 있습니까, 아니면 과도한 엔지니어링을 하고 있습니까?
CSS
export class A{#t}
JSX
const clamp = (min, val, max) => Math.max(min, Math.min(val, max)) const x = clamp(0, v1, a.length - 1) const y = clamp(0, v2, b.length - 1) const z = clamp(0, v3, c.length - 1)
이 조언은 '중복 방지'와 다소 상충됩니다. 중복된 코드를 과도하게 제거하면 과도한 엔지니어링이 발생할 수 있습니다. 그럼 어디에 선을 그어야 할까요? 개인적으로 저는 매직넘버 '3'을 사용합니다. 비슷한 패턴을 보이는 세 곳이 보이면 이제 제네릭 컴포넌트를 추출해야 할 시점이 아닐까 싶습니다.
파란색 버튼의 경우 새 구성요소를 만드는 것보다 최소한 패딩용으로 CSS 변수를 사용하는 것이 가장 좋은 해결책이라고 생각합니다.
예, 저는 우리가 좋아하는 것(Next.js, React, Vue 등)에 대해 이야기하고 있습니다. 앱이 DOM 요소 수준에서 많은 상호작용을 포함하지 않거나, 동적이지 않거나, 매우 단순한 경우 다른 옵션을 고려하세요.
TypeScript의 현재 목표는 주로 JavaScript 유형 검사이지만 항상 이렇지는 않았습니다. ES6 이전에는 "더 나은 JavaScript"를 만들려는 시도가 많았으며 TypeScript도 예외는 아니었습니다. 일부 기능은 그 초기로 거슬러 올라갑니다.
제대로 사용하기 어려울 뿐만 아니라 상당히 장황한 구조로 변환됩니다.
타입스크립트
type TreeNode<T> = {
left?: TreeNode<T>
value: T
right?: TreeNode<T>
};
function* traverse<T>(root: TreeNode<T>): Generator<T> {
if (root.left) yield* traverse(root.left)
yield root.value
if (root.right) yield* traverse(root.right)
}
자바스크립트
export class A {
#myFancyStateObject
}
공식 TypeScript 핸드북에서는 열거형 대신 간단한 객체를 사용할 것을 권장합니다. 노동조합 형태도 고려해 볼 수 있습니다.
네임스페이스는 ESM 모듈 이전의 솔루션이었습니다. 번들 크기가 커질 뿐만 아니라 네임스페이스가 전역적으로 사용되도록 의도되었기 때문에 대규모 프로젝트에서 이름 충돌을 피하기가 정말 어렵습니다.
타입스크립트
export class A{#t}
자바스크립트
const clamp = (min, val, max) => Math.max(min, Math.min(val, max)) const x = clamp(0, v1, a.length - 1) const y = clamp(0, v2, b.length - 1) const z = clamp(0, v3, c.length - 1)
네임스페이스 대신 ES 모듈을 사용하세요.
참고: 네임스페이스는 전역 라이브러리에 대한 유형 정의를 작성하는 데 여전히 유용합니다.
이러한 각각의 작은 트릭을 사용하면 번들에서 몇 바이트에서 수십 바이트를 절약할 수 있습니다. 꾸준히 바르시면 눈에 띄는 효과를 보실 수 있습니다.
예를 들어 빈 문자열은 거짓입니다. 정의되어 있고 비어 있지 않은지 확인하려면 다음과 같이 간단히 작성하면 됩니다.
const clampToRange = (n, {length}) =>
clamp(0, n, length - 1)
const x = clampToRange(v1, a)
// ...
저는 ==를 사용하여 null을 정의되지 않은 것으로 강제하거나 그 반대로 하는 것이 전적으로 타당하다고 생각합니다.
.btn-a {
background-color: skyblue;
padding: 4px;
}
.btn-b {
background-color: deepskyblue;
padding: 8px;
}
<button className='btn-a' onClick={handleClick}>
Show
</button>
// ...
<button className='btn-b' onClick={handleSubmit}>
Submit
</button>
대신:
enum A {
x, y
}
다음을 작성하세요:
var A;
(function (A) {
A[A["x"] = 0] = "x";
A[A["y"] = 1] = "y";
})(A || (A = {}));
대신:
namespace A {
export let x = 1
}
다음을 작성하세요:
var A;
(function (A) {
A.x = 1;
})(A || (A = {}));
개체의 속성이 변경되지 않도록 보호하기 위해 개체를 고정할 수도 있습니다.
각 번들러에는 webpack용 webpack-bundle-analyzer 및 Vite용 vite-bundle-analyzer와 같이 콘텐츠를 시각화하는 도구가 있습니다. 다음과 같은 도구는 번들과 관련된 일반적인 문제를 식별하는 데 도움이 됩니다.
이러한 도구 외에도 때때로 번들을 수동으로 읽어 불규칙성을 찾아내는 것이 좋습니다. 예를 들어, TypeScript 구성 오류로 인해 ES6 번들에서 ES5 도우미를 찾거나 ESM 프로젝트에서 CJS 도우미를 찾을 수 있습니다. 이러한 문제는 자동화된 도구로 포착되지 않을 수도 있지만 여전히 로딩 시간이 늘어나고 잠재적으로 가장 귀중한 자산인 사용자의 주의가 손실될 수 있습니다.
읽어주셔서 감사합니다. 즐거운 코딩하세요!
위 내용은 JavaScript 번들 크기를 최소화하는 실용적인 팁의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
