
<img src="/assets/img/2024-08-18-2024CurryinginJavaScriptInterviewProblems_0.png" />

안녕하세요 개발자 여러분,

잘 지내고 계시나요? 오늘은 JavaScript에서의 커링과 관련된 인터뷰 문제에 대해 이야기해보도록 하죠.

커링(Currying)이란 무엇인가요?

<div class="content-ad"></div>

한 예시로 이해해봅시다:

```js
function curriedFunction(a) {
  // 이 함수는 단일 인수 'a'를 받아서 다른 함수를 반환합니다.
  return function (b) {
    // 반환된 함수는 단일 인수 'b'를 받아 다시 다른 함수를 반환합니다.
    return function (c) {
      // 가장 안쪽 함수는 단일 인수 'c'를 받아 'a', 'b', 'c'의 합을 반환합니다.
      return a + b + c;
    };
  };
}

console.log(curriedFunction(1)(2)(3)); //출력: 6
/* 
  여기서 함수는 세 개의 인수를 하나씩 호출합니다.
  먼저, curriedFunction(1)은 'b'를 기대하는 함수를 반환합니다.
  그런 다음 반환된 함수가 (2)로 호출되어 
  'c'를 기대하는 또 다른 함수를 반환합니다.
  마지막으로 마지막 함수가 (3)으로 호출되어 
  합인 1 + 2 + 3 = 6을 계산하고 반환합니다.
*/
```

면접 문제 1:

n개의 인수에 대한 커링 함수를 구현하고, 비어있는 인수로 호출했을 때 값을 반환하세요.

<div class="content-ad"></div>

구현

```js
const sumOfNumbers = (...args) => {
  // 초기 인수는 'storage' 배열에 저장됩니다.
  const storage = [...args];

  // 인수가 제공되지 않은 경우, 합계로 0을 반환합니다.
  if (storage.length === 0) {
    return 0;
  } else {
    // 연이은 호출과 인수를 처리하는 'temp' 함수를 정의합니다.
    const temp = function (...args2) {
      // 새로운 인수(args2)를 'storage' 배열에 추가합니다.
      storage.push(...args2);

      // 현재 호출에서 인수가 전달되지 않은 경우 'storage' 배열을 합산하고 결과를 반환합니다.
      if (args2.length === 0) {
        return storage.reduce((a, b) => a + b, 0);
      } else {
        // 그렇지 않은 경우, 추가적인 연결을 위해 'temp' 함수 자체를 반환합니다.
        return temp;
      }
    };

    // 호출을 추가적으로 연결할 수 있도록 'temp' 함수를 반환합니다.
    return temp;
  }
};

console.log(sumOfNumbers(1)(2, 3)(2)(3)(4)(10)());
/* 연결 프로세스 설명:
  1. sumOfNumbers(1)은 'storage'가 [1]로 초기화된 'temp' 함수를 반환합니다.
  
  2. (2,3) => 'temp'가 이를 'storage'에 추가 => [1, 2, 3] 및 'temp' 반환.
  
  3. (2) => 'temp'가 이를 'storage'에 추가 => [1, 2, 3, 2] 및 'temp' 반환.
  
  4. (3) => 'temp'가 이를 'storage'에 추가 => [1, 2, 3, 2, 3] 및 'temp' 반환.
  
  5. (4) => 'temp'가 이를 'storage'에 추가 => [1, 2, 3, 2, 3, 4] 및 'temp' 반환.
  
  6. (10) => 'temp'가 이를 'storage'에 추가 => [1, 2, 3, 2, 3, 4, 10] 및 'temp' 반환.
  
  7. () => 'temp'가 인수를 감지하지 못해 'storage'의 합계를 반환: 1 + 2 + 3 + 2 + 3 + 4 + 10 = 25.
*/
```

인터뷰 문제 2:→

이전 전달된 값 기억하여 이전 값과 현재 값의 합계를 반환하는 함수입니다.

<div class="content-ad"></div>

구현

```js
const sumOfPreviousAndCurrentValue = () => {
  // 'sum'을 0으로 초기화합니다.
  let sum = 0;

  // 반환된 함수는 'num'이라는 숫자를 받아 'sum'에 추가합니다. 기본값은 0입니다.
  return function (num = 0) {
    sum += num;
    return sum; // 업데이트된 'sum'을 반환합니다.
  };
};

let sum = sumOfPreviousAndCurrentValue();
// 'sum'은 이제 누적 합을 계속 더할 수 있는 함수입니다.

console.log(sum(1)); // 첫 호출: 0 + 1 = 1, 따라서 1이 출력됩니다.
console.log(sum(4)); // 두 번째 호출: 1 + 4 = 5, 따라서 5가 출력됩니다.
```

위의 문제는 커링 기술에 대한 이해를 돕습니다.

질문이 있으면 댓글로 알려주세요. 이 스레드가 유익했다면 박수를 부탁드립니다.

<div class="content-ad"></div>

저에게 커피 사줘:→ 링크

자바스크립트에 대해 더 배우고 싶다면 이 사이트를 방문해보세요.

링크드인에서 나를 팔로우하세요.

# 쉽게 설명한 것들 🚀

<div class="content-ad"></div>

In Plain English 커뮤니티에 참여해 주셔서 감사합니다! 떠나시기 전에:

- 반드시 작가를 클립하고 팔로우하세요 👏
- 팔로우하기: X | LinkedIn | YouTube | Discord | Newsletter
- 다른 플랫폼 방문하기: CoFeed | Differ
- 더 많은 컨텐츠: PlainEnglish.io


자바스크립트 커링 Currying 관련 면접 질문


<img src="/assets/img/2024-08-18-HowdeferimprovestheperformanceofAngularAppAComparisontoif_0.png" />

앵귤러에서는 버전 17에서 @if 및 @defer를 도입했습니다. 둘 다 특정 조건이 참인 경우 화면에 요소를 렌더링합니다. 이제 두 가지가 조건부 렌더링을 한다면 두 가지 사이에는 무엇이 다른 것인지 궁금할 것입니다. 언제 어떻게 사용해야 할까요? 이를 통해 애플리케이션 성능을 향상하는 방법에 대해 알아봅시다.

# @if과 @defer 이해

## @if

<div class="content-ad"></div>

`@if`은 조건이 참일 때 컴포넌트를 렌더링하고 거짓인 경우 숨기는 기본 제어 흐름 데코레이터입니다.

```js
@if(conditon){
 <div>
   조건이 참일 때 표시할 내용
 </div>
}
```

## `@defer`

`@defer` 지시어는 조건이 true일 때 컴포넌트를 DoM에 렌더링합니다. 컴포넌트 렌더링을 true 조건이 될 때까지 지연시킬 수 있습니다.

<div class="content-ad"></div>

@defer (condition) {
<large-component />
}

# @if, @switch, @defer 비교

![이미지](/assets/img/2024-08-18-HowdeferimprovestheperformanceofAngularAppAComparisontoif_1.png)

# 언제 어떤 것을 사용해야 할까요?

<div class="content-ad"></div>

- **@if**: 즉시 렌더링이 필요하고 컴포넌트가 비교적 가벼운 간단한 조건에 이상적입니다.
- **@defer**: 복잡한 컴포넌트나 초기 사용자 경험에 중요하지 않은 컴포넌트에 가장 적합합니다.

# 결론

@if와 @defer는 조건부 렌더링의 목적을 달성하는 데 사용됩니다. 그러나 성능 영향은 다릅니다. 사용 사례를 신중히 고려함으로써 개발자는 애플리케이션 성능을 최적화하고 사용자 경험을 향상시키기 위해 @defer를 활용할 수 있습니다.


Angular 앱의 성능을 향상시키는 defer와 if 비교


![image](/assets/img/2024-08-18-SimplifyingAngularTemplateswithcombineLatestinNgRx_0.png)

Angular과 NgRx를 사용할 때 가장 흔한 과제는 상태 셀렉터들을 깔끔하고 가독성있게 효과적으로 관리하는 것입니다. combineLatest 함수는 이러한 문제에 강력한 해결책을 제공하며, 특히 Angular의 async 파이프와 ng-container와 함께 사용할 때 뛰어난 결과를 보여줍니다. 이 접근법을 사용하면 더 간결하고 유지보수가 쉬운 템플릿을 생성할 수 있어 가독성과 성능을 모두 향상시킬 수 있습니다.

## combineLatest 이해하기

RxJS의 combineLatest 함수는 NgRx가 의존하는 것으로, 여러 개의 옵저버블을 결합하는 데 사용됩니다. NgRx 셀렉터와 함께 사용할 때 상태의 여러 조각을 단일 옵저버블 스트림으로 결합할 수 있어 구성 요소에서 이를 구독할 수 있게 해줍니다.

<div class="content-ad"></div>

여기에 기본적인 예제가 있습니다:

```js
data$ = combineLatest([
  sample1: this.#store.select(sampleSelector1)),
  sample2: this.#store.select(sampleSelector2))
])
```

이 예제에서 data$는 selector 중 하나가 새 값이 발생할 때마다 sample1과 sample2를 포함한 객체를 발행하는 observable입니다. 이 결합된 observable은 Angular 템플릿에서 직접 사용할 수 있습니다.

# ng-conteiner와 async 파이프 활용하기

<div class="content-ad"></div>

가장 효과적인 방법 중 하나는 Angular 템플릿에서 combineLatest를 사용하는 것입니다. 이 방법은 ng-container와 async 파이프를 사용하는 것으로 시작합니다. 이 접근 방식은 템플릿을 간소화하는데 도움이 되며, 비동기 구독 수를 줄이는 방법으로 성능을 향상시킵니다.

다음은 구현하는 방법입니다:

```js
<ng-container *ngIf="data$ | async as data">
  <div>{ data.sample1 }</div>
  <div>{ data.sample2 }</div>
</ng-container>
```

# 장점

<div class="content-ad"></div>

combineLatest을 ng-container 및 async pipe와 함께 사용하는 것은 여러 가지 이점을 제공합니다:

- 단일 구독: combineLatest를 사용하면 템플릿에 async pipe가 하나만 필요하므로 구독 수가 줄어들고 템플릿 로직이 간소화됩니다.
- 깔끔한 템플릿: ng-container 지시문을 사용하면 단일 데이터 객체 내에서 모든 결합된 상태 선택기에 직접 액세스할 수 있어 템플릿을 간결하고 가독성 있게 유지할 수 있습니다.
- 성능 향상: 더 적은 구독은 더 적은 오버헤드를 의미하며, 특히 복잡한 구성 요소에서는 성능이 향상됩니다.
- 보일러플레이트 감소: observable$ | async as value" 지시문을 여러 개 관리하는 대신 하나만 관리하므로 템플릿의 보일러플레이트 코드 양이 줄어듭니다.

# 모두 함께 사용하기

두 가지 다른 선택기에서 사용자 세부 정보 및 환경 설정을 표시하는 구성 요소를 고려해보세요. combineLatest 없이는 템플릿이 이와 같이 보일 수 있습니다:

<div class="content-ad"></div>

```js
<div *ngIf="user$ | async as user">
  <div>{ user.name }</div>
</div>
<div *ngIf="preferences$ | async as preferences">
  <div>{ preferences.theme }</div>
</div>
```

combineLatest을 사용하면 다음과 같이 간소화할 수 있습니다:

```js
<ng-container *ngIf="data$ | async as data">
  <div>{ data.user.name }</div>
  <div>{ data.preferences.theme }</div>
</ng-container>
```

이 접근 방식은 더 깔끔하게 보이며 컴포넌트가 복잡해지더라도 더 효율적으로 확장할 수 있습니다.

<div class="content-ad"></div>

# 결론

Angular 템플릿에서 ng-container 및 async pipe와 함께 combineLatest를 사용하면 NgRx에서 상태 선택기를 더 효율적이고 깨끗하게 유지할 수 있는 방법을 제공합니다. 이 패턴을 채택하면 템플릿의 복잡성을 줄이고 코드를 더 쉽게 읽고 작성하며 유지할 수 있습니다.

다음 Angular 프로젝트에서 이 접근 방식을 시도해보고 코드베이스에 얼마나 큰 영향을 미칠 수 있는지 경험해보세요!

더 많은 Angular 팁과 트릭을 기대해주세요! 👨‍💻

<div class="content-ad"></div>

이 글을 즐겨 보셨다면 연결하고 싶으시다면 망설이지 마시고 LinkedIn에서 저를 팔로우해주세요!


NgRx에서 combineLatest를 활용하여 Angular 템플릿 만드는 방법

리액트 + 장고로 풀스택 ToDo 앱 프로젝트 만드는 방법


![image](/assets/img/2024-08-18-TheGoodandtheBadFront-EndToolsandTechniquesYouShouldKnow_0.png)

지난 몇 년 동안, $1.7B GenAI 스타트업에서 일하면서 다양한 프론트엔드 도구 및 기술을 접했습니다.

회사가 성장함에 따라, 우리 팀은 전 세계의 엔지니어들이 기여하는 조직화된 프론트엔드 저장소를 유지하는 방법에 대한 다양한 결정을 내려야 했습니다.

이 글에서는 이러한 도구에 대한 제 경험을 공유하고 "❌ 고려" 또는 "✅ 지지" 중 하나로 평가하겠습니다.

<div class="content-ad"></div>

- ❌ 고려해 보세요: 프로젝트에 대한 대안을 고려하는 것을 추천드립니다.
- ✅ 지지합니다: 망설임 없이 이것을 프로젝트에서 재사용할 것입니다.

# 코드 품질과 도구

## ESLint

🔍 고려

<div class="content-ad"></div>

설명: JavaScript 코드에서 문제를 식별하고 해결하여 일관된 코딩 표준을 시행하는 정적 코드 분석 도구입니다.

긍정적인 점:
ESLint는 버그를 찾아내고 일관된 코딩 표준을 분산된 팀 전체에 적용하는 데 도움을 줍니다. React를 위한 여러 규칙들로 확장 가능합니다.

부정적인 점:
ESLint는 느릴 수 있습니다. 제 경험상, 빌드 파이프라인 시간에 상당한 영향을 미치며, 캐싱 및 변경된 파일에만 실행하는 기술을 사용해도 그 시간을 감소시키기 어렵습니다.

일상적인 작업 흐름에서, 저는 커밋 전에 Git 후크로 ESLint를 실행합니다. 파일을 약간만 수정해도 ESLint가 보통 5-15초가 걸리는데, 이는 작은 커밋을 선호하는 저에게는 귀찮은 일일 수 있습니다.

<div class="content-ad"></div>

ESLint의 잠재적인 대체품으로 biome을 고려해 볼 수 있습니다. biome은 현재 ESLint 규칙을 모두 지원하지는 않지만 상당히 빠릅니다.

## Git 훅

✅ 지지

설명:
Husky나 pre-commit과 같은 도구로 관리되는 Git 훅은 코드베이스에서 작업하는 모든 사람이 변경 사항을 커밋하기 전에 동일한 작업을 수행하도록 보장합니다.

<div class="content-ad"></div>

긍정적으로 말씀드리자면, pre-commit Git 훅은 팀 전반에 걸쳐 일관된 관행을 강제함으로써 풀 리퀘스트를 올릴 때 빌드가 깨지는 횟수를 줄이는 데 도움을 줍니다. 여기에는 pre-commit 훅에 포함할 수 있는 몇 가지 작업이 있습니다:

- 변경된 파일 형식 맞추기
- 변경된 파일에 ESLint 실행하기
- 미임포트 파일 확인하기
- 순환 종속성 확인하기
- 커밋 메시지를 접두어(예: 티켓 번호)와 함께 형식 맞추기, 이렇게 함으로써 봇이 자동으로 Jira/Linear 티켓을 연결할 수 있습니다.

## TypeScript

✅ 지지합니다

<div class="content-ad"></div>

설명:
최근 몇 년 동안 TypeScript의 인기가 상당히 증가했지만, Svelte 창조자인 Rich Harris와 같은 사람들은 때로는 필수가 아니라고 주장합니다.

![이미지](/assets/img/2024-08-18-TheGoodandtheBadFront-EndToolsandTechniquesYouShouldKnow_1.png)

긍정적 측면:
전 세계의 엔지니어들과 함께 대규모 분산 코드베이스에서 작업 중이라면 TypeScript를 고려할 가치가 있습니다. ESLint보다 빠르게 실행되며, 출시하는 코드에 강력한 확신을 제공하고, 리팩토링을 쉽게 만듭니다.

부정적 측면:
TypeScript는 tsc를 실행해야 하므로 CI 파이프라인에 일부 추가 빌드 시간을 추가할 수 있습니다.

<div class="content-ad"></div>

또한, 특히 react-hook-form과 같은 복잡한 유형의 패키지를 다룰 때 지루할 수도 있습니다. 이러한 경우에 대해 TypeScript 특정 문제를 해결하는 데 종종 JavaScript 전용 프로젝트에는 존재하지 않는 버그를 디버깅해야 했습니다.

## 미사용 파일 식별 도구

✅ 추천

설명:
Unimported(더 이상 유지되지 않음)와 knip과 같은 도구는 코드베이스에서 사용되지 않는 파일을 식별하는 데 도움을 줍니다.

<div class="content-ad"></div>

긍정적:
코드를 정리할 때 사용하지 않는 파일을 놓치기 쉽습니다. 이러한 도구들은 삭제해도 되는 파일을 감지하여 코드베이스를 깨끗하고 효율적으로 유지하는 데 도움을 줍니다.

이 글을 쓰는 동안, Unimported가 더 이상 유지되지 않는 것을 알았습니다. 저는 직접 knip을 사용한 적은 없지만, Unimported에서 knip으로 마이그레이션하고 추가 기능을 탐색하는 노력을 할 가치가 있는 것으로 보입니다.

# 빌드 및 패키지 관리

## Vite

<div class="content-ad"></div>

### 환영합니다

소개:
빠른 개발 및 최적화된 프로덕션 빌드를 제공하는 차세대 프론트엔드 빌드 도구입니다.

긍정적인 점:
바벨에서 Vite로 전환하면 생산성이 크게 향상될 수 있습니다. 제 경험에 따르면 빌드 시간이 5분에서 40초로 줄었습니다.

게다가 Vite의 '즉시 서버 시작' 기능은 로컬 개발 서버를 즉시 시작하여 매일 소중한 시간을 절약할 수 있습니다.

<div class="content-ad"></div>

## 러나

✅ 추천

설명:
러나는 JavaScript 모노 레포지토리의 관리를 간단하게 만들어줍니다.

장점:
지금까지 러나를 사용하며 원활한 경험을 해왔어요. 주요 문제 없이 JavaScript 모노 레포지토리를 관리하는 데 신뢰할 만하고 안정적인 도구입니다.

<div class="content-ad"></div>

## 프로토콜 버퍼

✅ 지지

설명:
언어 중립적이고 플랫폼 중립적이며 확장 가능한 구조화된 데이터 직렬화 메커니즘으로, 분산 시스템 간에 효율적으로 데이터를 정의하고 교환하는 데 사용됩니다.

장점:
프로토콜 버퍼는 특히 수십 명의 엔지니어로 이루어진 대규모 코드베이스에서 API 표준에 대해 분산된 팀을 정렬하는 데 탁월한 도구입니다. 이들은 일관적이고 효율적인 데이터 형식을 제공함으로써 복잡한 응용 프로그램을 구축하는 프로세스를 간소화합니다.

<div class="content-ad"></div>

부정적인 측면:
그러나 Protocol Buffers를 설정하는 것은 복잡할 수 있고, 시스템에 익숙하지 않은 사람들에게는 도전적일 수 있는 학습 곡선이 있습니다.

부가 정보:
Protocol Buffers와 같은 코드 생성 도구가 실제로 어떻게 작동하는지 궁금했던 적이 있나요? Google Summer of Code 프로젝트 중에 Google의 도구 프레임워크에 기여했는데, 이를 깊이 있게 탐구하게 되었습니다. 해당 프레임워크는 현재 GitHub에서 약 300개의 별을 받고 있습니다.

# 테스트

## Jest를 사용한 단위 테스트

<div class="content-ad"></div>

**표를 고쳐주세요**

설명:
JavaScript 테스팅 프레임워크.

장점:
애플리케이션의 비즈니스 로직에 중점을 둔 유닛 테스트는 버그를 발견하는 데 효과적입니다. 예를 들어, 백엔드에서 데이터를 변환하거나 다양한 객체로 복잡한 API 요청을 생성하는 상황에서 유닛 테스트가 빛을 발합니다.

우리는 SWC를 사용하여 Jest의 유닛 테스트 실행 시간을 4분에서 1분 정도로 크게 줄였어요.

<div class="content-ad"></div>

Vitest를 사용하는 것 또한 테스트 속도를 향상시키는 좋은 방법일 수 있습니다.

부정적인 측면:
나는 React 컴포넌트에 대한 유닛 테스트를 작성하는 것을 좋아하지 않아요, 특히 버튼을 클릭하여 팝오버를 열거나 하는 단순한 상호작용을 위한 것들에 대해서 말이에요. 이러한 테스트는 구현 및 유지에 상당한 시간이 필요하나, 그에 비해 제한적인 가치를 제공합니다.

## Playwright

✅ 추천

<div class="content-ad"></div>

내용:
작가의 인기가 지난 몇 년 동안 상당히 증가했으며, 그로 인해 Playwright가 E2E에 대한 올바른 선택임을 확신하게 되었습니다.

![이미지](/assets/img/2024-08-18-TheGoodandtheBadFront-EndToolsandTechniquesYouShouldKnow_2.png)

장점:
나는 우리의 E2E 테스트 인프라를 구축하는 역할을 맡았고, 그 프레임워크로 Playwright를 선택했습니다. 내 경험은 매우 긍정적이었습니다. 가장 중요한 기능을 다루는 몇 가지 포괄적인 E2E 테스트에 초점을 맞추고, 각 구성 요소에 대한 작은 단위 테스트를 구현하기보다는 사용자의 경로를 따르도록 권장합니다.

우리는 관련 있는 E2E 테스트가 풀 리퀘스트에서 트리거되도록 시스템을 설정했으며, 실패하는 경우 엔지니어는 문제를 분석하기 위해 직접 Trace Viewer에 연결됩니다.

<div class="content-ad"></div>

부정적:
E2E 테스트 유지하는 일이 조금 지루할 수 있어요. 처음에는 개발자들이 새로운 기능과 함께 E2E 테스트를 작성하도록 했지만, 코드베이스가 발전함에 따라 기존 테스트를 유지하고 새로운 테스트를 작성할 전용 QA 팀이 필요하다는 점을 깨달았어요.

## UI 프레임워크와 라이브러리

### Mantine

✅ 추천

<div class="content-ad"></div>

**설명:**
Mantine은 완전한 오픈 소스 React 컴포넌트 라이브러리입니다.

**장점:**
Mantine은 이해하기 쉽고 프로젝트에 쉽게 적응하고 통합할 수 있는 우수한 컴포넌트 세트를 제공합니다. 라이브러리는 완벽하게 작동하며 주요 개발자가 Discord에서 매우 활발하게 활동하여 강력한 커뮤니티 지원을 제공합니다. 제 경험에서 Mantine과 관련된 어떤 문제도 발견하지 못했습니다.

매우 추천할 수 있습니다.

**## Highcharts**

<div class="content-ad"></div>

### 고려사항

**설명:**
다양한 대화형 시각화를 만들 수 있는 포괄적 차트 라이브러리입니다.

**장점:**
Highcharts에는 다양한 사용 사례를 다루는 복잡한 차트를 구축할 수 있는 잘 문서화된 API가 있습니다.

**단점:**
그러나 Highcharts는 유료 라이브러리이며, 대부분의 사용 사례에는 Chart.js와 같은 무료 대안이 충분할 수 있습니다.

<div class="content-ad"></div>

또 다른 단점은 TypeScript의 타입과 인터페이스가 하나의 거대한 파일로 통합되어 있어서 IDE의 성능을 상당히 느리게 만들 수 있다는 것입니다. 그 결과로 종종 온라인 문서를 의존해야 했습니다.

게다가 특정한 사용 사례에 대해서는 Highcharts가 제 요구사항을 충족시키지 못했기 때문에 필요한 차트를 구축하기 위해 D3를 사용해야 했습니다.

## D3

❌ 고려해 보세요

<div class="content-ad"></div>

**설명:**
복잡하고 사용자 정의된 데이터 시각화를 만들기 위한 유연한 JavaScript 라이브러리입니다.

**긍정적인 점:**
D3는 좀 더 간단한 라이브러리로 다루기 어려운 복잡한 계층 차트를 생성할 때 매우 가치 있는 도구입니다. 매우 유연하며 다양한 예제와 함께 상세한 문서가 제공되어 있어 사용자를 안내해줍니다.

**부정적인 점:**
하지만, D3는 높은 학습 곡선을 가지고 있습니다. 당신이 필요로 하는 것을 달성할 수 없는 상위 차트 라이브러리가 없을 때에만 사용하는 것을 추천합니다.

라이브러리의 복잡성이 매우 높기 때문에 문서의 튜토리얼과 예제에 많은 의존을 하게 될 것입니다.

<div class="content-ad"></div>

## dnd 킷

✅ 퍼스트<br>

설명:
dnd 킷은 드래그 앤 드롭 기능을 구현하는 라이브러리입니다.

긍정적인 면:
dnd 킷은 사용자가 폼 요소를 드래그하고 다시 배치할 수 있는 복잡한 중첩된 양식을 구축하는 데 훌륭하다고 생각합니다. 이러한 시나리오에서 제게 잘 도움이 되었습니다.

<div class="content-ad"></div>

# 상태 관리

## TanStack Query

✅ 추천

설명:
TanStack Query는 React 애플리케이션에서 API 호출과 서버 상태를 효과적으로 관리하는 강력한 라이브러리입니다.

<div class="content-ad"></div>

긍정적인 피드백:
TanStack Query를 사용하면 항상 긍정적인 경험만을 누릴 수 있어요. 데이터 검색, 캐싱 및 동기화를 간편하게 처리해주어, 직접 검색 로직을 구현하는 것보다 훨씬 쉽게 만들어줘요. 이것은 의심할 여지없이 모든 프론트엔드 프로젝트에 포함되어야 할 가장 중요한 라이브러리 중 하나에요.

## TanStack Table

✅ 추천

설명:
TanStack Table은 강력하고 사용자 정의 가능한 헤드리스 UI 라이브러리로, 테이블을 구축하는 데 사용됩니다.

<div class="content-ad"></div>

긍정적인 면:
TanStack Table을 사용한 경험은 전적으로 긍정적이었습니다. 이는 특정한 필요에 맞는 견고한 테이블 컴포넌트를 만들 수 있는 유연성을 제공합니다.

## Zustand

✅ 지지

설명:
Zustand은 React 애플리케이션을 위한 간단하고 확장 가능한 상태 관리 라이브러리입니다.

<div class="content-ad"></div>

긍정적:
Zustand은 React Context와 비교해 더 쉽고 확장 가능하기 때문에 React 프로젝트에서 상태를 관리하는 데 좋은 선택입니다.

## React hook form

❌ 고려 사항

Description:
React Hook Form은 React 애플리케이션에서 폼을 빌드하고 관리하는 인기 있는 라이브러리입니다.

<div class="content-ad"></div>

친절한 말투로 번역:

긍정적:
해당 라이브러리는 잘 작동하며 GitHub 커뮤니티가 크기 때문에 복잡한 폼을 만드는 데 필요한 기능을 제공합니다.

부정적:
TypeScript와 함께 사용할 때 문제를 겪었습니다. 특히 복잡한 폼의 유형 안정성 유지에 어려움을 겪었습니다. 재귀 폼 및 해당 유형 처리도 까다로웠습니다.

TanStack Form이나 Mantine Form과 같은 대안들은 TypeScript 관련 문제가 덜 발생할 수 있습니다.

# 유틸리티 라이브러리

<div class="content-ad"></div>

## Lodash

✅ Approve

설명:
Lodash는 편리한 함수들로 코드를 더 깔끔하고 읽기 쉽게 만들어줍니다.

긍정적:
Lodash 함수들은 코드를 보다 간결하고 가독성 있게 만들어줍니다. 제가 자주 사용하는 함수로는 groupBy, cloneDeep 등이 있습니다.

<div class="content-ad"></div>

내 코드를 더 깔끔하게 만들고 싶을 때는 종종 GPT에게 Lodash 함수를 사용하여 리팩토링해달라고 요청하곤 하는데, 결과적으로 대부분 개선이 있었습니다.

## Madge

✅ 추천

설명:
Madge는 코드 베이스에서 순환 종속성을 감지하고 방지하기 위한 도구입니다.

<div class="content-ad"></div>

긍정적인 측면:
Jest로 작성된 단위 테스트는 저장소 내에서 순환 종속성이있을 때 예기치 않은 실패를 일으킬 수있으므로 부실할 수 있습니다. Madge를 통합하여 이러한 문제를 피할 수 있습니다. Madge는 빠르기도 하기 때문에 작업 과정에 상당한 시간을 추가하지 않습니다.

부정적인 측면:
순환 종속성을 피하기 위해서는 많은 파일을 다른 위치로 리팩토링해야할 수도 있습니다. 새로운 기능을 시작할 때 파일을 어디에 놓고, 그들이 어떻게 참조되는지에 대해 신중해야 합니다. 미리 고려하지 않으면 나중에 전체 파일 구조를 재조직해야할 수도 있습니다.

## 덜

✅ 추천

<div class="content-ad"></div>

설명:
Less는 스타일 파일을 더 유지보수하기 쉽고 이해하기 쉽도록 도와주는 CSS 전처리기입니다.

긍정적인 측면:
Less를 사용하면 복잡한 스타일 작업을 할 때 스타일 파일을 더 쉽게 읽고 관리할 수 있습니다.

부정적인 측면:
IDE에서 Less 구문을 완전히 지원하지 않는 경우가 있어서 "선언으로 이동(Go to declaration)"과 같은 작업이 항상 작동하지는 않습니다.

저는 CSS 클래스 이름을 다루는 대신 Mantine와 같은 라이브러리를 사용하여 JSX 내에서 직접 DOM 요소를 스타일링하는 것이 더 효율적이라고 생각했습니다.

<div class="content-ad"></div>

예를 들어, 저는 이 방법을 선호합니다:

```js
// Mantine을 사용하여 패딩, 마진 및 배경을 가진 플렉스박스 사용
const BoxExample = () => {
  return (
    <Flex p="1rem" mb="1rem" bg="white" justify="center">
      Mantine Flex로 스타일링됨
    </Box>
  );
};
```

다음 예제보다:

```js
// styles.less
.styled-div {
  padding: 1rem
  background-color: white
  margin-bottom: 1rem
  display: flex
  justify-conent: center
}

const LessExample = () => {
  return <div className="styled-div">LESS로 스타일링됨</div>;
};
```

<div class="content-ad"></div>

저의 흔한 방식은 Mantine에서 제공하는 속성 (예: p, mb 등)을 최대한 활용하여 스타일을 적용하고, 필요할 때만 CSS 또는 Less로 되돌아가는 것입니다.

이 방식을 채택하면 레이아웃을 빠르게 이해할 수 있고, 외부 스타일 파일이 필요한 경우를 줄일 수 있습니다. JSX 코드에 속성이 과도하게 사용되어 가독성을 떨어뜨리는 것을 방지하면서 컴포넌트의 레이아웃을 이해하기 쉽게 유지할 수 있는 좋은 균형을 이룹니다. Tailwind처럼 가독성이 떨어지는 문제를 피하는 데에도 도움이 됩니다.

더 알아보기:


초보 프론트엔드 개발자들이 알아둬야할 도구와 기술


## 다음 Next.js 및 React.js 프로젝트를 최고의 10 가지 슬라이더 라이브러리로 업그레이드하세요! 원활한 이미지 표시와 동적 콘텐츠 쇼케이스를 위한 다양한 옵션을 발견해보세요. SwiperJS부터 React Image Gallery까지, 웹 애플리케이션의 기능성과 시각적 매력을 향상시킬 완벽한 슬라이더를 찾아보세요. 🌐💻✨

![이미지](/assets/img/2024-08-18-Top10SliderLibrariesForyourNextjsandReactjsProject_0.png)

🚀 Next.js 또는 React.js 프로젝트를 시작하고 사용자 인터페이스를 꾸미기 위한 이상적인 슬라이더 라이브러리를 찾고 있나요? 여기에서 끝나요! 🎉 이 블로그 포스트에서는 시각적 매력을 높일 뿐만 아니라 웹 애플리케이션의 기능성을 강화시킬 최고의 10 개 슬라이더 라이브러리를 엄선했습니다. 🌐 원활한 이미지 표시 또는 동적 콘텐츠 쇼케이스를 상상하고 계시다면, 당사의 목록은 Next.js 및 React.js 프로젝트에 맞는 다양한 슬라이더 옵션을 제공합니다. 발전적인 요구 사항에 적합한 완벽한 슬라이더 솔루션을 발견하기 위해 다재다능한 라이브러리의 세계로 뛰어들어보세요. 💻✨

시작해봅시다 👇

<div class="content-ad"></div>

# 1. 🌐 FullPage.js

![FullPage.js](/assets/img/2024-08-18-Top10SliderLibrariesForyourNextjsandReactjsProject_1.png)

[Demo](https://alvarotrigo.com/fullPage/)

[Documentation](https://alvarotrigo.com/fullPage/docs/)

<div class="content-ad"></div>

React를 위한 FullPage.js는 높은 수준의 풀 스크린 캐러셀 구성 요소로 높이 평가받습니다. 이 효율적인 전체 화면 페이지 슬라이더는 단일 페이지 애플리케이션 (SPA) 내에서 매끄럽고 수평 및 수직 스냅 스크롤 탐색을 만드는 데 뛰어납니다. 다양성으로 인해 다중 섹션 간의 원활한 전환을 가능하게 하며 React 기반 프로젝트에서 사용자 경험을 향상시키는 데 가치 있는 자산입니다.

# 2. 📱 SwiperJS

![SwiperJS 이미지](/assets/img/2024-08-18-Top10SliderLibrariesForyourNextjsandReactjsProject_2.png)

데모: https://swiperjs.com/demos

<div class="content-ad"></div>

**링크**: [문서](https://swiperjs.com/get-started)

SwiperJS, 또는 React Slider Swiper로도 불리는 이것은 매끄러운 사용자 경험을 제공하도록 설계된 견고한 모바일 터치 슬라이더 라이브러리입니다. 모바일 장치에서 최적의 성능을 위해 제작되었으며 부드러운 전환과 원활한 행동을 보장합니다. 이 다재다능한 라이브러리는 모바일 웹사이트에서부터 모바일 앱 및 네이티브/하이브리드 모바일 애플리케이션에 이르기까지 다양한 분야에서 활용됩니다. SwiperJS는 슬라이드의 애니메이션을 간편하게 만들어주며 이미지 지연 로딩 및 기본 전환 효과와 같은 편리한 기능을 제공합니다.

### 3. 🎢 React Slick Slider

![이미지](/assets/img/2024-08-18-Top10SliderLibrariesForyourNextjsandReactjsProject_3.png)

<div class="content-ad"></div>

데모: https://kenwheeler.github.io/slick/

문서: https://kenwheeler.github.io/slick/

Slick는 JavaScript 및 WordPress 플러그인으로 시작하여 독립 개발자에 의해 React에 효과적으로 통합된 것으로 유명합니다. 이 적응력은 Slick가 개발자 커뮤니티에서 널리 받아들여지고 다양하게 활용되고 있다는 점을 강조합니다. Slick는 반응형 슬라이더를 만들기 위한 최고의 옵션으로 각종 캐러셀 기능을 제공하여 눈에 띄는 페이딩 효과로 슬라이딩 경험에 세련미와 섬세함을 더합니다.

# 4. 🌟 React 반응형 캐러셀

<div class="content-ad"></div>

데모: [https://react-responsive-carousel.js.org/](https://react-responsive-carousel.js.org/)

문서: [https://react-responsive-carousel.js.org/#install](https://react-responsive-carousel.js.org/#install)

React Responsive Carousel 라이브러리는 강력하고 가벼운 컴포넌트로, 다양한 기능을 갖춘 캐로셀을 제작하는 데 특별히 뛰어납니다. 이 다재다능한 도구는 레이지 로딩, YouTube 자동 재생, 사용자 정의 섬네일, 외부 컨트롤 등 다양한 사용자 지정 옵션을 제공합니다. 사용자는 캐로셀을 수직 스크롤링용으로 맞추거나, 페이딩 및 프레젠테이션 모드와 같은 추가 효과를 적용할 수 있습니다. 그러나, 마우스 버튼을 떼거나 화면에서 손가락을 뗄 때 일부 다른 캐로셀 옵션만큼 부드러운 품질을 제공하지 못할 수도 있는 드래깅 기능에 대해 알아 두는 것이 중요합니다.

# 5. 🌀 React Flickity

<div class="content-ad"></div>

<img src="/assets/img/2024-08-18-Top10SliderLibrariesForyourNextjsandReactjsProject_4.png" />

Demo: [여기를 클릭해주세요](https://flickity.metafizzy.co/)
문서: [여기를 클릭해주세요](https://www.npmjs.com/package/react-flickity-component)

React Flickity는 React용으로 제작된 Carousel Component로, 터치 지원 및 반응형 캐러셀을 제공하여 맞춤형 네비게이션 구성 기능을 제공합니다. 원래 Desandro에 의해 만들어진 JavaScript 컴포넌트 Flickity를 기반으로 합니다. 이 React용 적응 버전은 제3자 개발자에 의해 제작되었습니다. 일부 대안과 비교했을 때 약간의 적응형 기능이 부족하지만, React Flickity는 포괄적인 문서 및 다양한 사용자 정의 옵션과 함께 제공되는 정교하게 제작된 캐러셀을 제공합니다.

# 6. 📲 React-swipeable

<div class="content-ad"></div>

![이미지](/assets/img/2024-08-18-Top10SliderLibrariesForyourNextjsandReactjsProject_5.png)

데모: https://commerce.nearform.com/open-source/react-swipeable/docs/

문서: https://commerce.nearform.com/open-source/react-swipeable/

React-Swipeable은 React용 간단하고 신뢰할 수 있는 캐러셀 구성 요소를 제공하여 여러 스와이프 패턴이 특징인 스와이프 가능한 캐러셀 항목을 개발할 수 있습니다. 옵션 범위가 다소 제한적이지만 사용자 친화성이 뛰어나고 구현이 직관적하여 신뢰할 만한 선택지입니다. React-Swipeable 캐러셀 구성 요소를 돋보이게 하는 것은 정확한 스와이프 패턴에 따라 슬라이더를 조정할 수 있는 독특한 기능으로, 비슬비한 요소에서 찾아보기 어렵습니다.

<div class="content-ad"></div>

# 7. 🔧 순수한 React 캐러셀

![이미지](/assets/img/2024-08-18-Top10SliderLibrariesForyourNext.jsandReact.jsProject_6.png)

데모: https://express-labs.github.io/pure-react-carousel/

문서: https://github.com/express-labs/pure-react-carousel#readme

<div class="content-ad"></div>

위대로 이름에서 알 수 있듯이 순수 React JS Carousel은 솔직하고 효과적인 캐러셀 라이브러리로서 캐러셀 구성 요소의 기본을 제공합니다. 이 라이브러리를 돋보이게 하는 것은 다른 캐러셀 라이브러리에서 보다 덜 흔한 슬라이드 차원 제어를 당신에게 부여하는 독특한 능력입니다. 또한 CSS 사용자 정의를 통해 레이아웃을 필요에 맞게 수정할 수 있는 유연성을 제공합니다. 커뮤니티 내에서의 폭넓은 인기는 종종 다른 라이브러리에서는 부재가 일반적인 확대 기능을 포함하고 있기 때문입니다.

# 8. 🚀 React Awesome Slider

![image](/assets/img/2024-08-18-Top10SliderLibrariesForyourNextjsandReactjsProject_7.png)

문서: [https://caferati.me/demo/react-awesome-slider](https://caferati.me/demo/react-awesome-slider)

<div class="content-ad"></div>

데모: https://caferati.me/demo/react-awesome-slider

React-Awesome-Slider 캐러셀은 원활한 전체 페이지 전환이 가능하도록 제작된 고품질이며 유연한 React 구성 요소로서 두드러집니다. 60프레임(초당 프레임)의 부드러운 경험을 제공하기 위해 설계되었으며 다양한 사용자 정의 옵션을 갖추고 있습니다. 제작에 이상적이며 이미지 및 비디오 갤러리를 슬라이더나 캐러셀 형태로 보여주기에 적합합니다. 효율성과 적응성을 제공하며 웹 개발 필요에 대한 신뢰성 있고 맞춤 가능한 솔루션으로 활용할 수 있습니다.

# 9. 🎡 누카 캐러셀

<img src="/assets/img/2024-08-18-Top10SliderLibrariesForyourNextjsandReactjsProject_8.png" />

<div class="content-ad"></div>

데모: https://commerce.nearform.com/open-source/nuka-carousel/

문서: https://commerce.nearform.com/open-source/nuka-carousel/docs

누카 캐러셀은 단순함과 강력한 기능을 능숙하게 결합한 리액트 캐러셀 라이브러리로 빛을 발합니다. 브랜드 웹사이트에서 사용자 경험을 향상시키기 위해 디자인된 이 라이브러리는 사용하기 쉽고 접근성이 좋은 캐러셀 솔루션을 제공합니다. 누카 캐러셀은 사용자 인터페이스와 동작을 맞춤 설정할 수 있는 완전 기능을 갖춘 슬라이더를 제공하여 디자인에 유연성을 제공합니다. 특히 세로 스크롤을 지원하며 스크롤, 페이드 및 3D 스크롤 세 가지 명확한 전환 옵션을 제공합니다. 또한 선택적 줌 기능이 추가로 제공됩니다.

# 10. 🖼️ 리액트 이미지 갤러리

<div class="content-ad"></div>

![이미지](/assets/img/2024-08-18-Top10SliderLibrariesForyourNextjsandReactjsProject_9.png)

데모: [여기를 클릭해주세요](https://www.lightgalleryjs.com/demos/react-image-gallery/)

문서: [이곳에서 확인해주세요](https://www.lightgalleryjs.com/docs/getting-started/)

다양한 React UI 컴포넌트 라이브러리와 프레임워크가 있지만, React Image Gallery는 독특한 캐러셀 컴포넌트로 빛을 발합니다. 이 독특한 도구를 사용하면 모바일 스와이프 제스처 지원, 썸네일 탐색, 전체 화면 기능, 사용자 정의 슬라이드 렌더링, RTL(오른쪽에서 왼쪽으로) 지원, 그리고 갤러리와 캐러셀에 대한 반응형 디자인과 같은 기능을 갖춘 이미지 갤러리 및 캐로셀을 만들 수 있습니다. 주목할 만한 옵션으로 페이지네이션 표시, 전체 화면 보기를 위한 아이콘, 썸네일을 중앙 캐로셀에 통합하는 기능을 제공합니다.

<div class="content-ad"></div>

이 라이브러리들은 React 애플리케이션에서 동적이고 인터랙티브한 이미지 디스플레이를 만들기 위한 다양하고 견고한 선택지를 제공합니다. 즐거운 코딩하세요! 🚀

더 많은 팁과 통찰을 얻으려면 Let’s Code Future를 방문해보세요. 이 정보가 도움이 되었다면 공유하고 업데이트 및 리소스를 위해 저희를 팔로우해주세요! 🌟👩‍💻👨‍💻

# Stackademic 🎓

끝까지 읽어주셔서 감사합니다. 떠나시기 전에:

<div class="content-ad"></div>

- 작가를 클로딩하고 팔로우해주세요! 👏
- 우리를 팔로우하세요 X | LinkedIn | YouTube | Discord
- 다른 플랫폼 방문하기: In Plain English | CoFeed | Differ
- 더 많은 콘텐츠: Stackademic.com


Nextjs와 Reactjs에서 사용하기 좋은 슬라이더 라이브러리


![Image](/assets/img/2024-08-18-10SoftwareDesignPatternsyoushouldknowtobecomePrincipalEngineer_0.png)

# 소개

처음에 주니어 개발자가 되었을 때, 당신의 코드는 플레이도 뱀처럼 보일 것입니다. 그러나 시니어 개발자로 발전하고 소프트웨어 디자인 패턴에 대해 배우면, 당신의 코드는 시스틴 성당처럼 보일 것입니다.

그러나 그 후에 주요 엔지니어로 발전하면, 사람들이 어리석은 웹사이트를 위해 시스틴 성당을 유지하길 원하지 않는다는 것을 깨닫고 플레이도 뱀을 만들기 위해 돌아갈 것입니다.

<div class="content-ad"></div>

이번 기사에서는 소프트웨어 디자인 패턴 10가지에 대해 배우게 되며 사용하는 장단점에 대해 이야기할 것입니다. 이는 매우 주관적이며 논란이 될 수 있습니다.

프로그래밍 역사상 가장 영향을 끼친 책 중 하나는 C++ 엔지니어 네 명으로 이루어진 "갱 오브 포"에 의한 디자인 패턴입니다.

프로그래머가 직면하는 반복적인 문제를 해결하기 위한 23가지 다양한 접근 방식을 제시하며, 이는 생성 패턴(객체 생성 방식), 구조 패턴(객체 간의 관계) 및 행동 패턴(객체 간의 통신 방식)으로 구분됩니다.

<div class="content-ad"></div>

프로 소프트웨어 엔지니어가 되는 것은 프로그래밍 언어의 구문을 외우는 것이 아니라 문제를 해결하는 능력에 관한 것입니다. 이 기사를 끝까지 따라가면 여러 가지 문제 해결 패턴을 이해하게 될 것입니다, 이것은 현대 앱 개발자들과 관련하여 어떻게 적용되는 지에 대한 것입니다.

# 소프트웨어 디자인 패턴이란?

디자인 패턴은 정말 흥미로운데, 스택 오버플로우에서 복사하여 붙여넣을 수 있는 알고리즘과는 다릅니다. 실제로 구현하기 위해 머리를 써야 합니다.

이를 모든 곳에 구현하려는 유혹을 느낄 수 있지만, 부적절하게 사용하면 코드베이스에 추가 복잡성과 보일러플레이트를 더할 수 있습니다.

<div class="content-ad"></div>

그 책은 성서가 아니며, 디자인 패턴을 인식하는 것이 프로그래머로서 능력을 향상시키는 데 도움이 된다는 점을 알고 있더라도 그 책에 대한 많은 비평이 있습니다.

# 싱글톤

첫 번째로 살펴볼 패턴은 싱글톤입니다. 이것은 매우 쉽게 이해할 수 있는 유형의 오브젝트로, 한 번만 인스턴스화될 수 있는 오브젝트입니다.

TypeScript에서 전역 앱 설정 데이터를 표현하기 위해 싱글톤 클래스인 settings를 구현할 수 있습니다. 이 클래스에는 정적 인스턴스 속성이 있을 것이며, 생성자를 비공개로 만들어 new 키워드로 인스턴스화할 수 없도록 할 것입니다.

<div class="content-ad"></div>

그런 다음, 이미 생성된 인스턴스를 확인하고 생성되지 않았다면 새로 생성하는 정적 get instance 메서드를 만듭니다. 이 메서드는 오직 하나의 객체만 생성될 수 있도록 보장합니다. 이것이 모두 멋지지만, 여기서 조금 미묘해지는 부분이 있습니다.

JavaScript에서는 객체 리터럴을 사용합니다. 또한 전역 데이터와 객체의 개념은 참조로 전달됩니다. 이 패턴(아래에 코드 제공)은 전역 객체를 생성함으로써 동일한 기본 특성을 갖게 됩니다.

이 패턴 자체는 실제로 필요 없는 추가적인 보일러플레이트일 뿐입니다. C++에서는 전혀 다른 이야기가 되지만, 핵심은 어떤 멋진 디자인 패턴을 구현하기 전에 언어의 내장 기능에 의존하는 것입니다.

# Prototype

<div class="content-ad"></div>

이제 프로토타입 패턴에 대해 알아보겠습니다. 이는 클론을 위한 멋진 용어에 불과합니다. 객체 지향 프로그래밍을 수행한 적이 있다면 상속에 익숙할 것입니다. 클래스를 서브클래스로 확장할 수 있는 상속의 개념입니다.

상속의 한 문제는 복잡한 코드 계층 구조로 이어질 수 있다는 점입니다. 프로토타입 패턴은 상속을 구현하는 대안적인 방법으로, 클래스의 기능을 상속받는 대신 이미 생성된 객체에서 기능을 가져옵니다.

이는 객체 간 기능을 공유하기가 훨씬 쉬워지도록 단순한 프로토타입 체인을 생성합니다. 특히 자바스크립트와 같이 동적 언어에서 프로토타입 상속을 기본적으로 지원하는 경우에 유용합니다. 상상해보세요. 우리에게는 "zombie"라는 객체가 있다고 가정합니다. 이것이 우리의 프로토타입입니다. 하지만 이제 이를 기반으로 새 객체를 만들고 싶습니다.

이 새 객체에도 "이름"이라는 속성이 있기를 원합니다. 우리는 새로운 속성들을 추가할 때, 해당 "zombie"를 프로토타입으로 전달하고 새 객체의 이름과 같은 추가 속성들을 지정해주면 됩니다. 흥미로운 점은 이 객체를 로그에 남길 때, 이름만이 아니라 "뇌 먹기" 메소드가 아니라는 것입니다.

<div class="content-ad"></div>

그러나 해당 메소드를 호출하려고 하면 여전히 작동합니다. 이것은 자바스크립트가 모든 메소드나 속성을 찾기 위해 프로토타입 체인을 따라 루트까지 이동하기 때문입니다.

프로토타입은 _proto_ 속성을 사용하여 객체로부터 언제든지 가져올 수 있지만, 이것은 현대적인 Best Practice가 아니며 대신에 Object.getPrototypeOf(chad)을 사용해야 합니다.

자바스크립트의 클래스에 대해 이야기할 때 prototype은 해당 생성자를 의미하며, 이는 원하는 경우 클래스를 추가 함수로 확장할 수 있다는 것을 의미합니다. 그러나 일반적으로 이것도 좋지 않은 실천으로 간주됩니다.

# Builder

<div class="content-ad"></div>

그럼, 이제 빌더 패턴으로 전환해 봅시다. 핫도그 가게를 운영 중이라고 상상해봅시다. 고객이 주문할 때 샌드위치에 무엇을 넣을지를 말해야 하는데, 기존의 생성자에 모든 옵션을 알려야 하는 것은 조금 복잡하고 모든 단계를 나중에 처리할 수도 있습니다.

빌더 패턴을 사용하면 생성자 대신에 메서드를 사용하여 단계별로 객체를 만들 수 있고, 빌드 로직을 완전히 다른 클래스로 위임할 수도 있습니다.

JavaScript에서는 각 메서드가 this를 반환하게 되는데, 이는 메서드 체이닝을 구현할 수 있도록 객체 인스턴스에 대한 참조입니다.

그 다음 체이닝된 메서드가 작동하지만, 항상 반환 값으로 객체를 받습니다. 이 패턴은 주로 jQuery와 같은 라이브러리에서 빈번히 사용되었지만, 최근 몇 년간은 약간 시대에 뒤떨어진 스타일이 되어갔습니다.

<div class="content-ad"></div>

# 팩토리

새 키워드 대신 객체를 인스턴스화하는 데 함수나 메서드를 사용하는 팩토리라는 패턴을 만날 수도 있습니다. 사소한 것처럼 들릴 수 있지만, 실제 예시를 보겠습니다.

모바일 앱을 개발 중이라고 상상해보죠. iOS와 안드로이드에서 모두 실행되는 크로스 플랫폼 앱을 만들고 있습니다. 두 플랫폼은 동일한 인터페이스를 가지고 있지만, 코드 내에서 어느 버튼을 표시할지 결정하기 위해 많은 조건을 확인하고 있는 상황입니다. 이는 유지보수하기 어려운 방식입니다.

대신, 어떤 객체를 인스턴스화해야 할지를 결정하는 서브 클래스나 함수를 만들어 사용할 수 있습니다. 이제 반복 로직을 사용하는 대신, 팩토리를 사용하여 렌더링될 버튼을 결정할 수 있습니다.

<div class="content-ad"></div>

# 파사드

이제 첫번째 구조용 패턴 파사드를 살펴볼 준비가 되었어요. 파사드는 건물의 얼굴이에요. 건물 안에는 사용자가 알 필요가 없는 각종 꿍꿍한 일들이 발생하는데요. 파사드는 코드베이스에서 다른 저수준 세부 사항을 숨기기 위한 간단화된 API입니다.

배관 시스템과 전기 시스템을 위한 클래스가 있다고 상상해봅시다. 이와 같은 시스템 안에는 압력과 전압과 같은 복잡한 것들이 많은데, 집에 사는 사람들은 이러한 저수준 세부 사항에 접근할 필요가 없어요.

그래서 우리는 저수준 시스템을 의존성으로 포함하고, 그러나 그들의 작업을 단순화하는 파사드 클래스를 만들어요. 예를 들어, 전기 및 배관 세부 사항을 단일 메서드로 결합하여 사용자는 단일 메서드로 전기와 배관을 간단히 켜거나 끌 수 있게 해줄 수 있어요.

<div class="content-ad"></div>

거의 모든 JavaScript로 설치하는 패키지는 특정한 방식으로 패싸드로 간주할 수 있으며 jQuery 같은 것은 더 귀찮은 하위 수준의 JavaScript 기능을 위한 패싸드의 훌륭한 예입니다.

# Proxy

다음 구조적 패턴은 우리가 살펴볼 프록시이며, 학교에서 대체 교사가 있는 것처럼, 이것은 대체물을 위한 멋진 단어일 뿐입니다.

프로그래밍에서는 대상 객체를 프록시로 대체할 수 있지만, 그렇게 하려면 왜 원하는 걸까요? 음, Vue.js의 반응성 시스템이 좋은 사례 연구입니다.

<div class="content-ad"></div>

Vue에서는 데이터를 생성하지만 프레임워크 자체가 데이터를 가로채서 데이터가 변경될 때 UI를 업데이트할 수 있는 방법이 필요합니다. 이를 처리하는 방법은 원래 객체를 프록시로 대체하는 것입니다.

프록시는 원래 객체를 첫 번째 인수로 취하고 두 번째 인수로 핸들러를 취합니다. 핸들러 내에서 get 및 set과 같은 메서드를 재정의할 수 있어서 객체의 속성이 액세스되거나 변경될 때마다 코드를 실행할 수 있습니다.

예를 들어, set 내에서 우리는 프레임워크에 다시 렌더링하도록 지시하고 original 객체의 데이터를 업데이트하기 위해 반영(reflect)를 사용할 수 있습니다. 최종 사용자는 이제 프록시를 원래 객체처럼 사용할 수 있지만, 이러한 부작용을 트리거할 수 있습니다.

프록시는 또한 메모리를 복제하는 데 비용이 많이 드는 매우 큰 객체를 다룰 때 흔히 사용됩니다.

<div class="content-ad"></div>

# Iterator

이제 행동 패턴 중 일부를 살펴볼 준비가 되었습니다. 먼저 이터레이터부터 시작해 보겠습니다. 이터레이터 패턴을 사용하면 객체 모음을 횡단할 수 있습니다.

현대 언어는 이미 이터프리터 패턴을 위한 추상화를 제공합니다. 배열 항목을 순회할 때 for 루프를 사용하면 이터레이터 패턴을 사용하게 됩니다.

하지만 JavaScript에 대해 제가 실망하는 한 가지는 원하는 시간 간격마다 쉽게 열 번 반복하고 싶은 범위 함수가 내장되어 있지 않다는 것입니다. 실제로 우리 자신의 이터레이터 패턴을 구현하여 이를 비교적 쉽게 수행할 수 있습니다.

<div class="content-ad"></div>

JavaScript에서는 다음 메서드가 있는 객체를 정의함으로써 그 작업을 수행할 수 있습니다. 해당 함수는 루프에서 현재 값을 나타내는 값을 반환해야 하며 종료 기준을 알기 위해 done 속성을 가져야 합니다.

이 경우 시작 값이 끝 값보다 작은 경우 계속 다음 단계로 이동할 것이지만 각 반복마다 시작 값을 단계적으로 증가시켜주어야 합니다. 결국 시작 값이 끝 값보다 커지면 done 속성이 true로 설정된 객체를 반환할 수 있고, 이는 JavaScript에게 반복 작업을 중단할 시점을 알려줍니다.

여기서 멋진 기술은 이 객체에 심볼 이터레이터를 추가하여, 결국 반복에 있어 그것을 일반적인 for...of 루프에 사용할 수 있게 할 수 있다는 점입니다. 요컨대, 반복 과정에서는 집합에서 시작하여 어떻게 처음부터 끝까지 이동할지 결정하는 코드를 작성합니다.

# 옵서버

<div class="content-ad"></div>

다음으로 살펴볼 패턴은 옵저버입니다. 옵저버는 푸시 기반 시스템입니다. 옵저버 패턴은 다른 객체에 의해 방송된 이벤트에 여러 개의 객체가 구독할 수 있게 합니다. 이것은 일대다 관계입니다.

현실 세계에서는 라디오 타워가 신호를 보내고 동시에 수신기가 수신하는 것을 생각해 볼 수 있습니다.

이 패턴은 앱 개발에서 많이 사용되며, 파이어베이스 같은 곳에서 데이터가 서버에서 변경되면 모든 클라이언트 앱이 해당 데이터를 구독하고 자동으로 최신 데이터로 업데이트됩니다.

우리의 코드에서는 RXJS 라이브러리를 가져와 이 패턴을 간단히 보여줄 것입니다. 이 라이브러리는 우리가 청취하고 싶은 데이터인 서브젝트 클래스를 제공합니다.

<div class="content-ad"></div>

이제 주제를 가지게 되면 해당 주제에 여러 가입을 추가할 수 있습니다. 주제는 모든 이러한 구독을 추적하고 데이터가 변경될 때마다 콜백 함수를 호출할 것입니다.

나중에 어느 시점에서는 next 메서드를 호출하여 주제에 새 값을 추가할 수 있습니다. 그럴 때마다 모든 구독이 알림을 받을 것입니다. 개인적으로 시간의 차원에 걸쳐 펼쳐지는 루프로 생각하는 것을 좋아합니다.

# 중재자

이제 중재자 패턴으로 넘어가 봅시다. 중재자는 매개자나 브로커와 같습니다. 비행기와 샐도로를 위한 클래스가 있다고 상상해보세요.

<div class="content-ad"></div>

여러 개의 활주로와 비행기가 있을 수 있고, 어떻게 하면 특정 활주로에 비행기가 착륙해도 좋은지 확인해야 합니다.

현재, 이를 수행하려면 모든 객체들이 서로 통신해야 합니다. 우리는 많-대-많 관계를 가지고 있는데, 실제로나 프로그래밍에서 상당히 위험합니다.

해결책은 활주로와 비행기 사이에 위치한 항공 교통 관제사처럼 중재자를 만드는 것입니다. 이 중재자는 조정과 통신을 제공합니다.

다음은 express.js 웹 프레임워크의 더 실용적인 예입니다. 미들웨어 시스템을 사용하여 들어오는 요청과 나가는 응답을 처리하며 미들웨어가 중간에 위치합니다.

<div class="content-ad"></div>

그것은 비행기처럼 모든 요청을 가로채서 적절한 형식으로 응답을 위한 런웨이로 변환합니다. 이것은 관심사의 분리를 제공하며 코드 중복을 제거합니다.

# 상태

그리고 이것은 우리를 열 번째이자 마지막 디자인 패턴 상태로 이끕니다. 여기서 객체는 유한한 상태에 따라 다르게 동작합니다.

코드에서는 상태나 데이터에 따라 여러 가능성을 처리하기 위해 조건 로직 또는 스위치 문을 사용해 왔을 것입니다.

<div class="content-ad"></div>

이런 식의 코드는 일반적으로 잘 확장되지 않습니다. 이 상태 패턴을 사용하면 하나의 기본 클래스로 시작하여 내부 상태에 따라 다양한 기능을 제공할 수 있습니다.

이 아이디어는 유한 상태 기계 및 Xstate와 같은 라이브러리와 관련이 있습니다. 목표는 오브젝트의 동작을 그것의 기본 상태에 따라 예측 가능하게 하는 것입니다.

이 예에서는 사람 클래스를 가지고, 그의 기분에 따라 다르게 생각하게 합니다. 현재는 switch 문을 사용하여 그렇게 하고 있지만, 다른 방법은 각 클래스 내에서 가능한 상태마다 별도의 클래스를 만드는 것일 수 있습니다. 동작이 다른 동일한 메소드가 있을 것입니다.

이제 사람 클래스에서 상태를 속성으로 설정하고, 그 메소드가 호출될 때마다 현재 상태로 위임합니다. 이는 상태가 변경될 때마다 객체가 완전히 다른 방식으로 동작하지만 동시에 API를 변경할 필요가 없거나 다수의 조건부 로직을 사용할 필요가 없다는 것을 의미합니다.

<div class="content-ad"></div>

# 크레딧

이 게시물을 작성하게 된 동기는 Youtube 채널 Fireship의 비디오였기 때문에 마음에서 우러나온 감사와 크레딧을 전합니다. 비디오를 시청하고 싶다면 [여기](링크)를 클릭해주세요.

# 팁 주기

# 요약하여 말하면 🚀

<div class="content-ad"></div>

인 플레인 잉글리쉬 커뮤니티에 참여해 주셔서 감사합니다! 떠나시기 전에:

- 반드시 박수 치고 작가를 팔로우하세요 👏
- 팔로우하세요: X | LinkedIn | YouTube | Discord | 뉴스레터
- 다른 플랫폼 방문하기: CoFeed | Differ
- PlainEnglish.io에서 더 많은 콘텐츠를 만나보세요


주니어 개발자가 알아둬야 할 10가지 소프트웨어 디자인 패턴


이러한 것을 잃어버리는 것은 예전에는 ES6 이전에 일반적인 두통이었습니다. 그런 다음 화살표 함수가 등장하면 과거의 문제가 사라졌습니다. 그렇다면 새로운 JavaScript 개발자는 왜 호출 컨텍스트의 차이를 배우려고 해야 할까요? (또는 상속, 호이스팅, 객체지향 원칙 등) 제가 이유를 보여드릴게요. 그 전에 간단하게 정의를 다시 한 번 살펴봅시다:

![이미지](/assets/img/2024-08-18-ExamplesoflosingcontextofthisinAngular_0.png)

## 함수 내에서 'this' :

JavaScript에서 'this'의 값은 함수가 호출되는 방식에 따라 달라집니다. (런타임 바인딩), 정의된 방식에 따라 달라지지 않습니다. 일반 함수가 객체의 메서드로 호출될 때 (obj.method()), 'this'는 해당 객체를 가리킵니다.

<div class="content-ad"></div>

## '화살표 함수'에서의 'this':

화살표 함수는 'this'를 부모 범위로부터 상속받습니다. 이 동작은 콜백 함수와 문맥을 유지하기 위해 화살표 함수가 특히 유용하다는 것을 의미합니다.

이 서론 다음에 저의 코딩 스타일 외에 이 간단한 Angular 컴포넌트에서 문제점을 찾으시면 얼마나 좋을까요:

```js
export type State = 'FAILED' | 'PERFECT';

@Component({
  ...
  template: `
      <input type="number" [formControl]="value"/>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class SelfValidatingFieldComponent {
  protected value = new FormControl(1, this.controlValidator);

  private innerStateThing: State = 'PERFECT';

  private controlValidator(control: AbstractControl): ValidationErrors | null {
    if (control.value < 2 && this.innerStateThing === 'PERFECT') {
      return null;
    }
    this.innerStateThing = 'FAILED';
    return { selfValidating: { value: '아이고, 이게 실패했네요' } };
  }
}
```

<div class="content-ad"></div>

간단한 입력 필드입니다. 여기에는 유효성 검사기가 있습니다. 유효성 검사기를 정의하여 이 필드는 일회용 필드입니다. 한 번 유효하지 않게 만들면 그대로 유지됩니다. 그 이유는 몰라도 되죠. 물론 이 코드는 제대로 작동하지 않을 것입니다.

![Image](/assets/img/2024-08-18-ExamplesoflosingcontextofthisinAngular_1.png)

디버깅해 보면 더욱 나빠집니다. 우리의 유효성 검사기가 두 번 호출됩니다. 먼저 Angular 내부의 FormControl2 클래스에서 this.validator(this)로 호출되고, 그 다음으로 util 순수 함수에서 호출됩니다.

```javascript
function executeValidators(control, validators) {
  return validators.map((validator) => validator(control));
}
```

<div class="content-ad"></div>

innerStateThing이 이를 FormControl2로 보고 두 번째에는 undefined로 볼 때 당신의 의도와는 다르게 동작합니다. 이런 상황이 발생하는 이유가 무엇일까요? new FormControl(1, this.controlValidator)은 우리의 validator를 FormControl 개체에 할당하고, 호출될 때 이를 this로 받게 됩니다. 두 번째 호출에 대해 말씀드리자면,

validator를 수정하고 다시 실패하게 만들어 봅시다. 이제 새로운 문제를 발견했다면 자유롭게 자랑해 보세요 (우리 클래스의 변경 사항을 강조했습니다):

```js
@Component({
  ...
  template: `
    <app-self-validating-field [customValidator]="customValidator"></app-self-validating-field>
  `,
})
export class App {
  private readonly treshold = 1;

  customValidator(val: number): boolean {
    return val < this.treshold;
  }
}

...
export class SelfValidatingFieldComponent {
  customValidator = input.required<CustomValidator>(); // <== 필수 사용자 지정 유효성 검사

  protected value = new FormControl(1);

  private innerStateThing: State = 'PERFECT';

  ngOnInit() {
    this.value.addValidators([this.controlValidatorFactory()]);
  }

  private controlValidatorFactory(): ValidatorFn { // <== 화살표 함수를 반환하는 팩토리, 컨텍스트는 SelfValidatingField입니다
    return (control: AbstractControl): ValidationErrors | null => {
      if (
        control.value < 2 &&
        this.customValidator()(control.value) && // <== 사용자 지정 validator 사용
        this.innerStateThing === 'PERFECT'
      ) {
        return null;
      }
      this.innerStateThing = 'FAILED';
      return { selfValidating: { value: 'oh no, this failed' } };
    };
  }
}
```

이제 controlValidatorFactory는 동작하지만 다시 오류가 발생했습니다.

<div class="content-ad"></div>

![Example of losing context of 'this' in Angular](/assets/img/2024-08-18-ExamplesoflosingcontextofthisinAngular_2.png)

Here's a clearer illustration. I assigned a function from App to a member of SelfValidatingField. Since it's a simple function, when calling it back from SelfValidatingField, even though its definition is in App, "this depends on how a function is invoked," resulting in it being undefined.

Fun fact: if I had used @Input instead of signal input this would be SelfValidatingFieldComponent.

The bottom line is, you never know where your function will be called from, so either:

<div class="content-ad"></div>

- 순수하게 만들어 보세요!
- 화살표 함수를 사용하여 속성 보유 `customValidator = (val: number): boolean =` 를 사용해 보세요!
- 팩토리를 사용해 보세요 (← 보세요, 야생 속의 디자인 패턴들!)

그리고 더 실용적이라고 말하는 친구에게 이 기사를 보내보세요!


Angular에서 this의 컨텍스트 정리


![이미지](/assets/img/2024-08-18-InterviewthiskeywordinJS_0.png)

이 글에서는 자바스크립트 함수 내의 this 키워드에 대해 이야기합니다. 함수는 호출될 때 항상 객체를 참조합니다.

객체 없이 직접 호출된 함수는 전역 객체로 간주됩니다. 즉, window 객체입니다.

this 키워드의 어려운 문제들을 해결해 봅시다. 궁금한 점 있으면 언제든지 댓글 남겨주세요. 빠른 대답해 드릴게요.

<div class="content-ad"></div>

예제로 이해해봅시다.

## 1. 질문:

```js
let emp = {
  name: "John",
  getName: function () {
    console.log(this);
  },
};

emp.getName();
```

## 답변:

<div class="content-ad"></div>

```js
{name: 'John', getName: ƒ} // emp object
```

## 설명:

getName 함수가 emp 객체에서 호출되었기 때문에 이것은 emp 객체 자체입니다.

## 2. 질문:

<div class="content-ad"></div>

```js
function foo() {
  console.log(this);
}

foo();
```

## 답변:

```js
window; // window 객체
```

## 설명:

<div class="content-ad"></div>

```js
foo() === window.foo();
```

함수를 객체 없이 호출할 때는 `window` 객체에 의해 호출된 것을 의미하며, 이러면 `foo` 안에서 `this` 키워드는 `window`를 가리킵니다.

## 3. 질문

```js
function foo() {
  console.log(this);

  function bar() {
    console.log(this);
  }

  bar();
}

foo();
```

<div class="content-ad"></div>

## Answer:

```js
window;
window;
```

헷갈리시면 설명해 드릴게요.

## 설명:

<div class="content-ad"></div>

```js
function foo() {
  console.log(this);

  function bar() {
    console.log(this);
  }

  window.bar(); // window
}

window.foo(); // window
```

foo와 bar를 호출할 때 window를 추가했는데, window없이 호출할 때와 동일합니다.

우리가 논의한 대로, this는 함수를 호출한 객체입니다.

어디에서 호출했는지 중요하지 않습니다. 호출한 객체에 의해 결정됩니다.

<div class="content-ad"></div>

인터뷰-2: 자바스크립트에서 값에 의한 호출 및 참조에 대한 대화

인터뷰-3: 당신은 자바스크립트에서 이 키워드를 읽고 있습니다

인터뷰-4: 자바스크립트에서 호이스팅 및 데드 존


자바스크립트에서의 this 란 무엇일까


![이미지](/assets/img/2024-08-18-StopUsingletorWhyItsNeedlessinJavaScriptTypeScriptAdvancedJSTS2024_0.png)

이미 let 키워드를 수백만 번 정도 만났을 가능성이 높습니다. 이것은 처음에는 은총 같은 것처럼 보이는 JavaScript (그리고 확장되어 TypeScript까지)의 기능 중 하나입니다.

들고 있는 블록 범위 변수를 선언하는 방법이 마침내 있습니다! var이 호이스팅으로 혼란을 야기하고 직관적이지 않은 버그를 만드는 시대는 끝났습니다.

하지만 여기에 주목할 점이 있습니다: 2024년에는 코드에서 let을 사용하는 것이 가장 불필요한 일 중 하나일 수 있습니다.

<div class="content-ad"></div>

그렇다고요. 이제 let을 사용하는 것을 그만두는 시간입니다.

const로 바꾸어야 하는 경우와 가끔씩 let이 TypeScript 파일에서 여전히 자리를 차지해야 하는 이유에 대해 안내해 드릴게요.

# let의 부흥과 몰락 🐑

우선 과거로 돌아가봅시다. ES6 이전에는 var을 사용했었죠. 기능적이었지만 심각하게 결함이 있었습니다. var은 블록 스코프를 존중하지 않았는데요, for 루프 내에서 var를 선언해도 해당 변수가 루프 외부에서 계속 접근 가능했습니다.

<div class="content-ad"></div>

혼란을 불러일으키고 버그 코드를 유발하는 것은 바로 요것. ES6(혹은 ECMAScript 2015)은 let과 const를 도입함으로써 게임을 바꿨어. 갑자기 우리에게는 블록 단위 변수가 생겼지!

더 이상 var 악몽은 없어! let은 문제를 해결해 줘서 순식간에 인기를 끌었어. 몇 년간 씨름해 온 문제들을 해결해 주니까 말이야.

그런데 여기서 한 가지, const가 동시에 소개되었는데, 대부분의 상황에서 우월한 옵션인 것으로 평가되고 있어.

# 왜 const가 기본값이 되어야 하는 이유 🐠

<div class="content-ad"></div>

자, 함께 고려해 봅시다: 변경 불가능성은 최고입니다. 우리의 대부분의 일상 프로그래밍에서는 예측 가능하고 이해하기 쉽며 부작용이 없는 코드를 작성하기 위해 노력합니다.

이것이 const의 역할입니다. const를 사용하면 이 값이 변경되지 않을 것이라고 자신과 다른 사람들에게 말하는 것입니다.

그것은 보장입니다 - 변수가 코드의 중간에서 새 값으로 갑자기 바뀌지 않을 것이라는 약속입니다.

![이미지](/assets/img/2024-08-18-StopUsingletorWhyItsNeedlessinJavaScriptTypeScriptAdvancedJSTS2024_1.png)

<div class="content-ad"></div>

이렇게 하면 코드를 읽고 유지하는 것이 더 쉬워집니다. const로 선언된 변수를 한눈에 보면 즉시 그 목적을 파악할 수 있습니다: 이 값은 고정되어 있다는 것을 알 수 있어요.

반면에 let은 불확실성을 도입합니다. let으로 선언된 변수를 볼 때 나중에 값이 변경될지 확신할 수 없습니다. 그 변수를 정신적으로나 도구를 통해 추적해야 하는데, 이는 인지 부담을 더하게 됩니다.

내 경험상 코드를 검토할 때, let으로 선언된 변수를 const로 쉽게 변경할 수 있는 경우가 자주 있어요. 개발자들이 변수가 나중에 변경되지 않을 경우에도 습관적으로 let을 기본으로 선택하는 듯합니다.

# let 사용의 문제점 🐲

<div class="content-ad"></div>

let 키워드의 주요 문제는 불필요한 가변성을 초래한다는 것입니다. let을 사용하여 무언가를 선언하는 것은 너무 쉽지만 후에 그것이 처음에 왜 가변이어야 하는지 잊기 쉽습니다.

다음은 간단한 예시입니다:

![이미지](/assets/img/2024-08-18-StopUsingletorWhyItsNeedlessinJavaScriptTypeScriptAdvancedJSTS2024_2.png)

이 예시에서 let을 사용하는 것은 해 Harmless 해 보일 수 있지만, 자신에게 물어보세요 - userCount가 정말 가변이어야 했나요?

<div class="content-ad"></div>

당신이 쓴 코드를 const로 바꾸고 로직을 다시 구성했으면 코드가 더 명확하고 기능적일까요?

| <img src="/assets/img/2024-08-18-StopUsingletorWhyItsNeedlessinJavaScriptTypeScriptAdvancedJSTS2024_3.png" /> |
| :-----------------------------------------------------------------------------------------------------------: |

와우! 더 깨끗한 코드, 덜 가변성이 있고, 쉽게 따라가기가 쉬워졌어요.

# 언제 let을 사용해야 할까요? 🎒

<div class="content-ad"></div>

그래서 let을 완전히 버릴까요? 그렇지 않아요. let에 대한 합리적인 사용 사례가 있습니다. 하지만 생각하는 것보다 그 수가 더 적고 희소합니다.

- 반복 횟수: 무언가를 반복해야 할 때 let이 종종 필요합니다.

for 루프가 좋은 예입니다:

![이미지](/assets/img/2024-08-18-StopUsingletorWhyItsNeedlessinJavaScriptTypeScriptAdvancedJSTS2024_4.png)

<div class="content-ad"></div>

- 여기서 i는 각 반복마다 변경되어야 하므로 let을 사용하는 것이 옳은 선택입니다.
- 변경 가능한 변수: 값이 실제로 변경되어야 하는 변수가 있는 경우에는 const 대신 let을 사용하는 것이 적절합니다.

![이미지](/assets/img/2024-08-18-StopUsingletorWhyItsNeedlessinJavaScriptTypeScriptAdvancedJSTS2024_5.png)

이 경우, 재할당은 로직에 중요합니다.

하지만 이러한 시나리오는 생각보다 덜 흔합니다. 종종 let이 필요하다고 느껴지는 것은 const로 재구성되어 명확성이나 기능을 잃지 않을 수 있습니다.

<div class="content-ad"></div>

# 더 나은 코드를 위한 도구와 팁들 🎥

코드를 더 향상시키고 싶으신가요? let 사용을 최소화하고 const의 힘을 극대화하기 위한 도구와 팁 몇 가지를 소개합니다:

- 린터: ESLint가 당신의 친구입니다. ESLint를 설정하여 불필요한 let 사용 시 경고 또는 오류를 표시하도록 설정할 수 있습니다. 이렇게 하면 let을 사용하기 전에 두 번 생각하게 됩니다.
- 리팩터링 도구: Prettier나 VSCode의 내장 리팩터링 도구와 같은 도구를 사용하면 빠르게 let을 const로 변환할 수 있습니다. 그냥 우클릭하고 마법이 일어나는 걸 보세요.
- 동료 코드 리뷰: 팀원들에게 코드 리뷰 과정에서 let 사용에 대해 질문하도록 권유해보세요. "이것이 정말 가변이어야 할까요?"라고 물어보는 것은 팀 내에서 불변성에 대한 사고 방식을 심어줄 수 있습니다.

# let 선언 완화의 고급 수준 💖

<div class="content-ad"></div>

혼란을 해결하는 다른 방법을 찾고 있다면, 선언 부분이 당신을 구조해 주는 구명조끼가 될 수도 있어요.

이것을 읽기 어렵게 만드는 이유는 초기 값을 머릿속에 유지하고 읽는 동안 발생하는 변이를 지켜봐야 한다는 점입니다.

![이미지](/assets/img/2024-08-18-StopUsingletorWhyItsNeedlessinJavaScriptTypeScriptAdvancedJSTS2024_6.png)

해결 방법: 함수를 호출하세요.

<div class="content-ad"></div>

<img src="/assets/img/2024-08-18-StopUsingletorWhyItsNeedlessinJavaScriptTypeScriptAdvancedJSTS2024_7.png" />

let을 사용하지 말고 formattedAddress 변수를 변이시키는 대신, 형식을 처리하는 함수를 호출하여 일찍 반환할 수 있습니다. 이렇게 하면 가변성이 없어지고 코드가 더 깔끔해집니다.

# 결론: 불변성 수용하기

요약하자면, 현대의 JavaScript와 TypeScript에서는 let은 규칙보다는 예외여야 합니다. const를 기본으로 사용함으로써 코드를 더 예측 가능하고 읽기 쉽게 만들며 버그 발생 가능성을 줄일 수 있습니다. 물론 let이 필요한 경우도 있지만, 그런 경우는 신중하게 고려해야 합니다.

<div class="content-ad"></div>

키보드 위에 손가락이 떠다니면서 'let'을 입력하려고 할 때, 한 순간 멈춰서 '이것이 정말 가변이어야 할까?' 물어보세요. 대부분의 경우 그 답은 아닐 겁니다.

2024년에는 적어도 불필요한 곳에서는 'let' 사용을 그만두는 해가 되었으면 좋겠네요.

독해해 주셔서 감사합니다! 이 글이 도움이 되었다면 동료들과 공유해 주시고, 댓글에서 계속 대화를 이어나가요.

즐거운 코딩하세요!

<div class="content-ad"></div>

# 친근한 한국어 번역 🚀

In Plain English 커뮤니티의 일원이 되어 주셔서 감사합니다! 떠나시기 전에:

- 작가를 박수로 격려하고 팔로우해주세요 ️👏️️
- 저희를 팔로우해주세요: X | LinkedIn | YouTube | Discord | Newsletter
- 다른 플랫폼에서도 만나보세요: CoFeed | Differ
- PlainEnglish.io에서 더 많은 콘텐츠를 즐겨보세요


Posts