4_21ee.log

Discriminated Union

Sun, 08 Sep 2024 05:05:55 GMT

Discriminated Union

Discriminated Union은 번역하면 구별된 유니온이라는 뜻으로 리터럴 멤버 프로퍼티가 있는 클래스가 있다면, 그 프로퍼티로 유니온 타입을 구별할 수 있다는 개념이다.

흔하게 접할 수 있는 타입 코드를 하나 살펴보자.

interface RoundIcon {
  shape: "circle";
  radius: number;
  color: string;
}

interface SquareIcon {
  shape: "square";
  width: number;
  height: number;
  color: string;
}

RoundIcon과 SquareIcon은 리터럴 타입의 shape이라는 프로퍼티를 공통으로 가지고 있다.

이러한 경우 우리는 shape의 타입을 통해 특정 객체의 정확한 타입을 알아낼 수 있다.

type Icon = RoundIcon | SquareIcon;

const renderIcon = (icon: Icon) => {
    if (icon.shape === 'circle') {
      // icon은 RoundIcon 타입!
      icon.radius;
      // icon.width <- X
    } else {
      // Icon 타입에서 shape가 circle이 아닌 타입이므로 여기서 icon은 SquareIcon 타입!
      icon.width
      // icon.radius <- X
    }

여기서 shape와 같이 특정한 리터럴을 가진 객체를 식별할 수 있는 프로퍼티를 구별 프로퍼티라 표현하고, RoundIcon과 SquareIcon을 유니온한 타입을 구별된 유니온(Discriminated Union)이라 표현한다.

Example

각각 여러 개의 타입이 동일한 이름의 리터럴 타입 프로퍼티(구별 프로퍼티)를 가지고 있다면, 그 여러 개의 타입을 구별해낼 수 있다는 점을 활용해 타입의 버전 관리를 할 수 있다.

type DTO = |
{
  version: undefined, // 버전 0
  name: string;
} | {
  version : 1,
  firstName: string;
  lastName: string;
} | {
  version : 2,
  firstName: string;
  middleName: string;
  lastName: string;
} | ...

real-world usage

이 구별된 유니온 타입을 활용하는 대표적인 예시가 Redux의 액션 객체이다.

액션 객체는 type이라는 구별 프로퍼티를 가지고 있고, switch문을 통해 이 프로퍼티를 기준으로 분기 처리를 한다. 즉, 타입이 좁혀진다.

function todosReducer(state = [], action) {
  switch (action.type) {
    case "ADD_TODO": {
      return state.concat(action.payload);
    }
    case "TOGGLE_TODO": {
      const { index } = action.payload;
      return state.map((todo, i) => {
        if (i !== index) return todo;

        return {
          ...todo,
          completed: !todo.completed,
        };
      });
    }
    case "REMOVE_TODO": {
      return state.filter((todo, i) => i !== action.payload.index);
    }
    default:
      return state;
  }
}

Exhaustive Check

interface RoundIcon {
  shape: "circle";
  radius: number;
  color: string;
}

interface SquareIcon {
  shape: "square";
  width: number;
  height: number;
  color: string;
}

export type Icon = RoundIcon | SquareIcon;

function getIconArea(icon: Icon) {
  if (icon.shape === "circle") {
    return icon.radius ** 2 * PI;
  }
  if (icon.shape === "square") {
    return icon.width * icon.height;
  }
}

위와 같이 유니온 타입의 Icon이 있고 유니온으로 묶인 각 타입들을 모두 대응하는 함수가 있는 상황이라 했을 때, 새로운 아이콘 타입을 추가하고 싶다면 Icon과 getIconArea를 모두 수정해 주어야 한다.

이때 Icon이 추가되었으면 getIconArea에도 조건문을 추가해 주어야 한다라는 일종의 가이드를 두고 싶은 경우, exhaustive 검사를 추가할 수 있다.

exhaustive 검사는 다음과 같이 해당 블록에서 추론한 타입이 never 타입과 호환되는 것처럼 작성하면 된다.

function getIconArea(icon: Icon) {
  if (icon.shape === "circle") {
    return icon.radius ** 2 * PI;
  }
  if (icon.shape === "square") {
    return icon.width * icon.height;
  }
  const _exhaustiveCheck: never = icon; // Here!
}

새로운 타입을 추가한 상황이라면, 마지막 타입에서 추론되는 새로운 타입은 never 타입이 아닐 것이기 때문에 never 타입에 할당할 수 없어 에러가 발생한다.

// error: 'TriangleIcon' is not assignable to 'never'

이렇게 에러를 발생시킴으로써 새로운 타입이 추가되었을 때 함께 변경되어야 하는 부분의 누락을 방지할 수 있다.

requestIdleCallback

Mon, 12 Aug 2024 04:41:16 GMT

requestIdleCallback이란?

브라우저가 유휴 상태(idle)일 때 실행할 콜백을 예약할 수 있는 메서드.

이 메서드를 사용하면 브라우저 메인 스레드가 바쁠 때는 해당 작업을 연기하고, 한가할 때 수행할 수 있다. 따라서 우선순위가 낮은 백그라운드 작업을 수행할 때 유용하다.

Usage

var handle = window.requestIdleCallback(callback[, options])

callback: 유휴 상태에 호출할 함수. IdleDeadline 객체를 인수로 받음
options: 옵셔널 매개변수. 콜백이 반드시 호출되어야 하는 최대 시간을 나타내는 timeout 속성을 가짐

IdleDeadline 객체

callback 함수에게 전달되는 객체로, 다음과 같이 구성됩니다.

timeRemaining(): 브라우저가 다음 작업을 실행하기 전까지 얼만큼의 시간이 남았는지를 밀리초 단위로 반환
didTimeout: 브라우저가 아직 유휴 상태가 되지 않았지만, 설정한 timeout 시간이 지나 콜백이 호출되었음을 나타내는 boolean 값

언제 사용할까?

기존에는 필수적이지 않은 작업을 추후에 실행되도록 개발자가 직접 예약하는 것이 매우 번거로웠지만, 브라우저는 언제 유휴 상태가 되는지 알고 있기 때문에 requestIdleCallback라는 API가 등장하게 되었다.

요즘 웹사이트에서는 실행해야 할 스크립트가 매우 많다. 그래서 스크립트를 최대한 빨리 실행해야 하지만, 동시에 메인 스레드를 오래 점유하여 사용자에게 방해가 되지 않도록 하는 것이 중요하다. 따라서 자바스크립트의 실행에 있어서 최적화가 필요한 경우 requestIdleCallback을 사용하면 좋다.

사용 예시

유휴 상태에 실행할 콜백 함수를 requestIdleCallback에게 넘겨주면 된다.

function myNonEssentialWork(deadline) {
  // 유휴 시간 동안 실행하기
  while (deadline.timeRemaining() > 0 && tasks.length > 0) {
    doWorkIfNeeded();
  }

  if (tasks.length > 0) {
    // 해야 할 일이 남았다면
    requestIdleCallback(myNonEssentialWork); // 다음 유휴 때 마저 실행하기
  }
}

requestIdleCallback(myNonEssentialWork);

단, 브라우저가 매우 바쁜 상황이라면 콜백이 호출되기 까지 오랜 시간이 걸릴 수 있다.

나중에 실행되어도 괜찮지만, 특정 시간 안에는 실행됐으면 하는 상황이라면 timeout 옵션을 주어 해결할 수 있다.

requestIdleCallback(processPendingAnalyticsEvents, { timeout: 2000 });

2초라는 시간이 지나서 콜백이 실행되면, deadline 객체는 다음과 같이 구성된다.

timeRemaining()은 0을 반환함
didTimeout은 true가 됨

단, timeout 옵션을 주는 것은 사용자에게 중단이 발생(버벅거림)할 수 있어 주의가 필요하다. 가능하다면 브라우저가 콜백을 호출할 시점을 결정하도록 놔두는 것이 좋다.

호환성 문제

이 메서드는 실험적 기능으로, 현재 대부분의 브라우저에서 지원하지만 Safari(iOS)에서는 지원되지 않는다.

따라서 메서드의 사용 가능 여부를 확인한 다음, 지원하지 않는다면 환경이라면 setTimeout으로 직접 구현하거나 폴리필을 사용해야 한다

if ("requestIdleCallback" in window) {
  // Use requestIdleCallback to schedule work.
} else {
  // Do what you’d do today.
}

항해 플러스 프론트엔드 1기 후기 - 추천? 비추천?

Thu, 23 May 2024 08:43:16 GMT

About Me

우선 저는 타 부트캠프를 통해 개발을 시작했고, 일을 하다가 퇴사한지 이제 2달정도 되어가는 2년차 프론트엔드 개발자입니다. 현재는 항해 플러스 프로그램을 수료한지 1주도 채 지나지 않은 따끈따끈한 상태이고 약 2-3달 동안의 여정도 돌아볼겸 항해플러스를 고민하고 있는 다른 주니어 개발자 분들을 위해 후기를 작성해보려고 합니다.

항해 플러스에 들어오기 전 갖고 있던 고민

주니어 개발자들이라면 대부분 비슷하겠지만 저 또한 프론트엔드 개발자로 일하면서 항상 최신 기술을 따라잡는 것과 실무에서의 깊이 있는 경험 부족이 고민이었습니다. 특히 React와 같은 프레임워크를 더 깊이 있게 공부하고, CI/CD, TDD와 같은 실무에서 중요하지만 경험하기 어려운 부분에 대해 더 배우고 싶었고 이러한 갈증을 해소하기 위해 방법을 알아보던 중에 항해플러스를 알게 되어 참여하게 되었습니다.

왜 항해 플러스였나요?

항해 플러스 프로그램을 선택하게 된 결정적 계기는 현직자를 대상으로 한다는 점과 시니어 코치진의 멘토링이었습니다. 현업에서 활동 중인 전문가들의 멘토링을 통해 실무에서 바로 적용할 수 있는 기술과 노하우를 배우고 싶었고, 다른 동료 개발자들과 소통하며 서로의 고민을 공유할 수 있는 좋은 기회가 될 것이라고 생각했습니다.

항해 플러스 FE 코스의 장점

React 심화 학습: 기본적인 사용법을 넘어, 고급 기능과 최적화 기법까지 배우며 실무 스킬을 레벨업 할 수 있었습니다.
실전 프로젝트: CI/CD, 프론트 TDD, 디자인패턴, 성능 최적화 등 현직에서는 경험하기 어려운 다양한 주제를 다루는 프로젝트를 통해 실전 감각을 키울 수 있었습니다.
시니어 코치진의 멘토링: 풍부한 경험을 가진 코치진의 멘토링을 통해 문제 해결 능력과 실무에 대한 이해도가 크게 향상되었습니다. 개발자 네트워킹: 동료 개발자들과의 협업을 통해 다양한 시각을 접하고, 현업 개발자들과의 네트워킹을 통해 넓은 인적 네트워크를 구축할 수 있었습니다.

항해 플러스 이전과 이후

기술적 성장: 심화된 React 학습과 다양한 실전 프로젝트를 통해 기술적 역량이 향상되었습니다.
마음가짐의 변화: 개발에 대한 자신감이 생기고, 새로운 도전에 대한 두려움이 줄어들었습니다.
개발자 네트워크: 동료들과의 협업과 네트워킹을 통해 다양한 인적 자원을 확보하게 되었습니다.

항해 플러스에 투자한 시간, 돈이 아깝진 않은가요?

분명 누군가는 항해플러스를 통해 얻는게 분명히 존재하지만 그래도 좀 비싼게 아니냐고 생각할 수 있다고 생각합니다. 그치만 항해 플러스에서의 기술적 성장, 실무 경험, 그리고 소중한 인맥을 통해 얻은 경험을 발판삼아 제가 개발자로서 한 단계 더 성장할 수 있는 시간이 되었다고 생각하기에, 투자한 시간과 돈이 전혀 아깝지 않습니다.

항해 플러스 코스를 고민하고 있는 개발자들에게

현업에서 새로운 자극을 원한다거나 이직을 생각하고 계시다거나 공부를 하려고 생각만 하고 시작하지 못하고 계신 저와 같은 주니어 프론트엔드 개발자분들이라면 여유가 되신다면 한번 항해플러스에 도전해보시는걸 추천드립니다. 하지만 내가 노력하는 만큼 얻어갈 수 있는곳이 항해플러스이기 때문에 자칫 가볍게 생각하고 오신다면 아무것도 얻어가지 못할 수도 있으니 단단히 각오하고 시작하시길 바랍니다,,, 화이팅~!🔥🔥🔥

테스트 전략 For FE

Thu, 25 Apr 2024 07:58:34 GMT

프론트엔드 개발에서의 테스트의 중요성

프론트엔드 개발에서 테스트는 애플리케이션의 안정성과 품질을 보장하는 핵심요소이다. 사용자 인터페이스(UI)의 다양한 상호작용을 검증하고, 예상치 못한 버그를 사전에 발견하여 사용자 경험을 향상시키는 데 중요한 역할을 한다. 왜냐하면 테스트를 통해 코드의 신뢰성을 높이고, 개발 과정에서 발생할 수 있는 오류를 최소화할 수 있기 때문이다.

테스트 종류와 적용시기

단위 테스트(Unit Test)
- 가장 작은 코드 단위의 기능을 검증
통합 테스트(Integration Test)
- 여러 컴포넌트 또는 시스템의 상호작용을 검증
E2E 테스트(End-to-End Test)
- 사용자의 관점에서 애플리케이션의 흐름을 전체적으로 검증

테스트 도구 선택 기준

테스트 도구 선택은 프로젝트의 요구 사항, 개발 팀의 선호도, 그리고 기존 개발 환경과의 호환성을 고려해야한다. Jest, Mocha, Cypress 등 다양한 테스트 도구가 존재하며, 각 도구는 고유의 특징과 장단점을 가지고 있다.

왜냐하면 적절한 테스트 도구의 선택은 테스트 과정의 효율성과 효과성을 결정짓기 때문이다.

테스트 자동화의 중요성

테스트 자동화는 개발 과정을 가속화하고, 반복적인 테스트 작업을 줄이며, 테스트의 일관성을 유지하는 데 중요하다. CI/CD 파이프라인에 테스트를 통합하여 코드 변경 사항마다 자동으로 테스트를 실행할 수 있다.

왜냐하면 테스트 자동화를 통해 개발자는 더 많은 시간을 품질 높은 코드 작성에 할애할 수 있으며, 신속한 피드백을 통해 개발 과정을 개선할 수 있기 때문이다.

결론

프론트엔드 개발에서 테스트는 애플리케이션의 품질과 안정성을 보장하는 데 필수적이다. 적절한 테스트 종류의 선택, 테스트 도구의 적용, 그리고 테스트 자동화의 구현은 효과적인 테스트 전략의 핵심 요소이다.

왜냐하면 이를 통해 개발 과정의 효율성을 높이고, 최종 사용자에게 높은 품질의 애플리케이션을 제공할 수 있기 때문이다.

좋은 테스트의 조건

1. 실행 속도가 빨라야 한다.

테스트의 실행 속도가 빠르다는 것은 코드를 수정할 때마다 빠른 피드백을 받을 수 있다는 의미이다. 이는 개발 속도를 빠르게 하고, 테스트를 더 자주 실행할 수 있도록 한다.

2. 내부 구현 변경 시 깨지지 않아야 한다.

작은 리팩토링에도 테스트가 깨진다면 코드를 개선할때 믿고 의지할 수 없을 뿐 아니라, 오히려 테스트를 수정하는 비용을 발생시켜 코드 개선을 방해하는 결과를 낳게 된다.

3. 버그를 검출할 수 있어야 한다.

테스트가 기대하는 결과를 구체적으로 명시하지 않거나 예상 가능한 시나리오를 모두 검증하지 않으면 제품 코드에 있는 버그를 발견하지 못할 수 있다. 그러므로 테스트 명세는 구체적이어야 하며, 모의 객체의 사용은 최대한 지양하는 것이 좋다.

4. 테스트의 결과가 안정적이어야 한다.

테스트는 외부 환경의 영향을 최소화해서 언제 어디서 실행해도 동일한 결과를 보장해야 한다. 이러한 외부 환경은 현재 시간, 현재 기기의 OS, 네트워크 상태 등을 포함하며, 직접 조작할 수 있도록 모의 객체나 별도의 도구를 활용해야만 한다.

5. 의도가 명확히 드러나야 한다.

테스트 코드를 보고 한눈에 어떤 내용을 테스트하는지를 파악할 수 있어야 한다. 그렇지 않으면 추후에 해당 코드를 수정하거나 제거하기가 어려워져서 관리 비용이 늘어나게 된다. 테스트 준비를 위한 장황한 코드가 반복해서 사용되거나 결과를 검증하는 코드가 불필요하게 복잡하다면 별도의 함수 또는 단언문을 만들어서 추상화시키는 것이 좋다.

테스트 전략의 중요성

모든 요소를 100% 만족하는 테스트를 작성하는 것은 사실상 불가능하다. 그렇기에 프로젝트, 서비스 모듈 등의 특성에 따라 어떤 것을 포기하고 어떤 것을 얻을 것인가를 잘 판단해서 전략을 세워야 한다. 특히 프론트엔드 코드는 그래픽 사용자 인터페이스(GUI)와 밀접하게 관계되어 있고 사용자의 다양한 실행 환경을 고려해야 하기 때문에 다른 플랫폼에서 사용되는 전략을 그대로 사용할 수 없다. 시각적 요소, 서버와의 통신, 사용자 인터페이스(UI)를 통한 입력 등을 각각 어떻게 테스트 해야 할 지 고민하며 자신만의 전략을 세워야 한다.

핵심 웹 지표

Mon, 25 Mar 2024 07:05:09 GMT

핵심 웹 지표란?

구글에서 만든 지표로 웹사이트에서 뛰어난 사용자 경험을 제공하는 데 필수적인 지표를 일컫는 용어.
구글에서 핵심 웹 지표로 꼽는 지표
- 최대 콘텐츠풀 페인트(LCP: Largest Contentful Paint)
- 최초 입력 지연(FID: First Input Delay)
- 누적 레이아웃 이동(CLS: Cumulative Layout Shift)
이 외에 특정 문제를 진단하는 데 사용될 수 있는 지표
- 최초 바이트까지의 시간(TTFB: Time To First Byte)
- 최초 콘텐츠풀 시간(FCP: First Contentful Paint)

최대 콘텐츠풀 페인트(LCP)

페이지가 처음으로 로드를 시작한 시점부터 뷰포트 내부에서 가장 큰 이미지 또는 텍스트를 렌더링하는 데 걸리는 시간
- 뷰포트 내부에서 큰 이미지와 텍스트 는 다음과 같이 정의
  - 내부의
  - poster 속성을 사용하는
  - url()을 통해 불러온 배경 이미지가 있는 요소
  - 텍스트와 같이 인라인 텍스트 요소를 포함하고 있는 블록 레벨 요소
    - 이 블록 레벨 요소에는
      ,
      등이 포함된다.

개선방안
- 텍스트는 언제나 옳다.
- 이미지를 불러오는 방법 변경.

최초 입력 지연(FID)

사용자가 페이지와 처음 상호 작용할 때부터 해당 상호 작용에 대한 응답으로 브라우저가 실제로 이벤트 핸들러 처리를 시작하기까지의 시간을 측정한다.
모든 입력에 대해 측정 X, 최초의 입력 하나에 대해서만 그 응답 지연이 얼마나 걸리는지 판단.
구글에서 정의하는 사용자 경험(RAIL)
- Response : 사용자의 입력에 대한 반응속도. 50ms 미만으로 이벤트를 처리할 것
- Animation : 애니메이션의 각 프레임을 10ms 이하로 생성할 것
- Idle : 유휴 시간을 극대화해 페이지가 50ms 이내에 사용자 입력에 응답하도록 할 것
- Load : 5초 이내에 콘텐츠를 전달하고 인터랙션을 준비할 것
  
  ⇒ 이 가운데 최초 입력 지연은 R에 해당하는 응답에 초점을 맞추고 있다.

최초 입력 지연이란 화면이 최초에 그려지고 난 뒤, 사용자가 웹페이지에서 클릭 등 상호작용을 수행했을 때 메인 스레드가 이 이벤트에 대한 반응을 할 수 있을 때까지 걸리는 시간을 의미한다. 그리고 이 시간은 메인 스레드가 처리해야 하는 다른 작업이 많을수록 느려진다.

개선방안
- 실행에 오래 걸리는 긴 작업을 분리
- 자바스크립트 코드 최소화
- 타사 자바스크립트 코드 실행의 지연
  - 타사 스크립트는 대부분 웹페이지 로드에 중요한 자원이 아니므로