coding- w00se

[우아한테크코스] 페이먼츠 2단계 회고

w00se — Fri, 13 May 2022 15:55:05 +0900

제어 컴포넌트와 비제어 컴포넌트

Keep

- 제어 컴포넌트와 비제어 컴포넌트의 차이를 알게 됐다.

- 페이먼츠 1단계에서는 제어 컴포넌트만 사용했지만 2단계에서는 용도에 맞게 제어/비제어 컴포넌트를 적용했다.

Problem - Try

1. DOM을 적절하게 활용하지 못했다.

- 비제어 컴포넌트로 Form을 구현할 때 input 태그에 있는 value에 접근하기 위해서 ref를 사용했다.

- ref를 이용하는 방법이 잘못된 방법이라 생각하진 않는다. 하지만 ref 이외의 DOM에 접근하는 방법을 몰랐기 때문에 아쉬운 점으로 적었다.

- Form 태그의 onSubmit 이벤트 발생 시 전달받은 event.target 객체와 태그의 id를 같이 활용하면 ref를 사용하지 않고 input 태그의 value에 접근할 수 있다.

예시 코드

const handleSubmitForm = event => {
    event.preventDefault();

    const inputValue = event.target['input-test'].value;
    
    console.log(inputValue);
  };

  return (
    <>
    	...
      <Form onSubmit={handleSubmitForm}>
        <Input id="input-test" />
        ...
      </Form>
    </>
  );

- 이뿐만 아니라 pattern 속성처럼 HTML 태그에 유용한 기능들이 있다. 따라서 MDN 공식 문서의 input 태그 속성들과 다른 예시 코드를 보면서 HTML 속성을 잘 활용하는 법에 대해서 공부하려 한다.

컴포넌트 디렉터리 분리

Keep

- 컴포넌트의 수가 증가되고 컴포넌트 디렉터리가 복잡해졌다. 불편함을 느끼고 컴포넌트 디렉터리 관리 방법에 대해서 찾아봤고 그중 atomic 디자인을 공부하고 비슷하게 적용했다.

- 컴포넌트와 디렉터리 분리에 대해서 앞으로도 꾸준히 고민해야겠다.

Problem - Try

1. Atomic 디자인을 적용하려 했지만 현실과 타협을 했다.

- Atomic 디자인 패턴은 최소 단위인 Atom 컴포넌트를 활용해서 Molecules, Organism 계층의 컴포넌트를 만들어가는 패턴이다. 하지만 미션에서는 Atom부터 다시 구현해서 적용하지 않고, 계층 별로 Atom -> Molecules -> Organism 순으로 유연하게 분리만 진행했다. 따라서 'Atomic 디자인을 적용시켰다!'의 느낌보다는 '컴포넌트를 Atom, Molecules, Organism이라는 디렉터리에 분리해서 관리했다.'의 느낌에 가깝다.

- Atomic 디자인도 좋은 패턴이지만, 현재는 '컴포넌트 디렉터리를 분리하는 기준'이 필요하다. 따라서 Atomic 디자인을 더 연습하기보다는 컴포넌트 디렉터리를 분리하는 기준에 대해 찾아보고 스스로에 맞는 방법을 선택하려 한다. 현재로써는 '이 컴포넌트가 공유되는가?'를 기준을 사용하고 있다.

[React] 리액트 파일 확장자를 jsx로 하는 이유

w00se — Wed, 4 May 2022 10:32:14 +0900

리액트 파일은 통상적으로 .js 대신 .jsx 확장자를 사용합니다.

이런 컨벤션은 JSX가 표준 Javascript가 아니기 때문에 발생했다고 합니다.

즉 파일 내부에 표준 Javascript 문법만 사용됐다면 파일 확장자로 .js가 적절합니다.

반면에 jsx나 Typescript처럼 파일 내부에 표준 Javascript 이외에 다른 코드가 있다면 해당 파일의 확장자는 .js가 아닌 다른 확장자로 지정한다고 합니다.

예를 들어 jsx가 사용된 파일 확장자는 jsx로, typescript가 작성된 파일 확장자는 .ts로 지정합니다.

참고 자료

https://stackoverflow.com/a/46169521

[우아한테크코스] 페이먼츠 1단계 회고

w00se — Fri, 29 Apr 2022 16:59:32 +0900

컴포넌트 작성 및 분리

Kepp

이번 미션의 목표는 CDD(Component-Driven Developmenet)에 따라 UI를 구성하고 재사용하는 것이다.
미션의 목표에 맞게 작은 컴포넌트부터 개발했다. 그리고 컴포넌트의 재사용을 고민하면서 개발했다.

Problem - Try

컴포넌트를 작은 단위로 나누어서 개발했지만 조립해서 잘하지 못했다.
- 아래는 이번 미션의 입력 폼 부분에 대한 예시 이미지이다.
- 입력 타입과 너비 등이 다르지만 모두 Label과 Input 컴포넌트를 조립해서 만든 LabeledInput 컴포넌트를 사용했다.
- 이런 방식으로 진행하니 컴포넌트를 담고 있는 페이지에서 가독성이 떨어지는 현상이 발견됐다.
- 따라서 작은 컴포넌트를 조립해서 입력 종류에 따라 컴포넌트를 만들었다면 가독성이 떨어지는 문제가 해결될 거 같다.

예시 코드

기존 예시 코드

// CardAddPage.jsx
// 카드 번호에 대한 input
<LabeledInput
value={convertedCardNumbers.join('-')}
handleInputChange={handleChangeCardNumbersInput}
invalidMessage={MESSAGE.INVALID_CARD_NUMBER}
inputProps={{
  type: 'text',
  width: '318px',
  maxLength: 19,
  placeholder: 'ex. 0000-0000-0000-0000',
  isValid: cardAddCondition.cardNumbers,
}}
inputLabelProps={{
  label: '카드 번호',
}}
/>
// 만료일에 대한 input
<LabeledInput
value={convertedExpiredDate}
handleInputChange={handleChangeExpiredDateInput}
invalidMessage={MESSAGE.INVALID_EXPIRED_DATE}
inputProps={{
  type: 'text',
  width: '137px',
  maxLength: 5,
  placeholder: 'MM / YY',
  isValid: cardAddCondition.expiredDate,
}}
inputLabelProps={{
  label: '만료일',
}}
/>

개선 예정 예시 코드

// CardAddPage.jsx
// 카드 번호에 대한 input
// CardNumberInput과 ExpiredDateInput은 각각 하위 컴포넌트인 Label과 Input 컴포넌트를 조립해서 만든 컴포넌트로 가정
<CardNumberInput />
// 만료일에 대한 input
<ExpiredDateInput />

stateless하게 작성한 Input 컴포넌트를 테스트하는 방법
- 이번 미션에서 작성한 Input 컴포넌트는 외부에서 상태 값과 상태 값 변경 함수를 주입받는다.
- 즉, input 태그의 value와 onChange를 상위에서 주입받는 형태이다.
- 해당 컴포넌트는 상태 값과 함수를 자유롭게 전달하는 개발 환경에서는 문제없었다. 하지만 컴포넌트를 테스트하는 storybook을 이용할 때 문제가 생겼다.
- 예를 들어 상태 값 변경 함수에 구현한 입력 값 검증 기능을 storybook에서 테스트를 할 수 없었다.
- 실제 컴포넌트의 동작과 테스트의 동작이 달라서 storybook을 이용하여 개발하는 의미가 퇴색됐다.
- 이를 해결하기 위해 storybook에서 상태 값을 주입할 수 있는 방법에 대해 공부하려 한다. 또한 잘 작성된 storybook 예시 코드를 확인하여 적절한 방법을 찾으려 한다.

상태 값 관리

Keep

프로젝트를 시작할 때 pages라는 디렉터리에 각 페이지를 구현하도록 설계했다.
각 페이지는 해당 페이지에서 필요한 상태 값을 갖도록 구현했다. 페이지와 관련된 상태 값이 한 곳에 있어서 쉽게 상태 값 변경 흐름을 파악할 수 있었다.

Problem - Try

비즈니스 로직과 UI 코드가 잘 분리되지 않았다.(확신은 없지만 그렇게 보인다.)
- 페이지는 UI 코드이다. 반면 상태 값과 상태 값을 처리하는 함수들은 비즈니스 로직(도메인 영역)이라 생각한다.
- 때문에 페이지 내부에 상태 값과 관련된 함수들이 존재한다는 것은 비즈니스 로직과 UI 코드가 분리되지 않은 것이라 생각한다. 이는 유지 보수를 어렵게 만든다.
- 따라서 비즈니스 로직과 UI 코드를 분리하는 방법에 대해 찾아보고 리팩터링해야 한다. 지금 떠오르는 방법은 비즈니스 로직에 관련된 코드를 CustomHook으로 작성하는 것이다.
페이지 별로 상태 값을 공유하는 방법에 대한 고민이 필요하다.
- 현재 미션에는 하나의 페이지만 존재하기 때문에 페이지 내부에서 상태 값을 관리하는 것이 충분하다.
- 하지만 추후에 요구사항 추가로인해 새로운 페이지가 추가되면 페이지 간의 상태 값 공유가 필요할 수 있다.
- 따라서 상태 값을 공유하는 방법에 대해 고민할 필요가 있다. 현재는 Context API의 도입을 생각하고 있다.

[Javascript] Eslint 설정 파일 옵션 env, parserOptions

w00se — Thu, 21 Apr 2022 16:32:45 +0900

env

.eslintrc.json의 env
- 스크립트의 실행 환경을 명시하는 곳으로, 실행 환경에 맞는 전역 변수들을 사전에 정의할 수 있습니다.
- 예를 들어 아래의 예시 코드처럼 jest: true를 설정하면 jest 파일에서 describe, test, expect 등의 함수들이 no-undef 규칙에 걸리지 않는 것을 확인했습니다.

env: {
  jest: true
}

env에 설정할 수 있는 옵션은 여기서 확인 가능합니다.
es2021 옵션
- 공식 문서에 의하면 es2021: true 옵션을 사용하면 ECMAScript 2021의 전역 변수들을 사전에 정의하고 ecmaVersion parser option도 12로 설정한다고 합니다.

parserOption

eslint에서 사용하는 parser의 option을 설정할 수 있다.
ecmaVersion은 프로젝트에 사용할 ECMAScript 버전을 명시하는 옵션이다.
ecmaVersion: latest는 ecmaVersion: 2022와 같다.
프로젝트에서 사용하는 ecmaVersion에 맞게 parser의 버전을 설정하면 된다.

[우아한테크코스] 유튜브 미션 회고

w00se — Tue, 22 Mar 2022 23:45:04 +0900

https://pixabay.com/ko/photos/글쓰기-작가-메모-펜-공책-923882

bottomup 좋다. 하지만, 최소한의 설계는 하고 진행하도록!

전역 state관리 및 옵저버 패턴 활용

전역 store에서 상태값을 관리했다.
상태 값에 변화가 있을 때, 변화가 있는 상태 값을 구독하고 있는 컴포넌트를 렌더링한다.

const state = {
  testNum: 100,
  testString: 'hello',
}

// 상태 값 별로 구독 리스트를 따로 관리하면, 상태 값이 변경됐을 때 구독된 컴포넌트들만 렌더링할 수 있다.  
const components = {  
  testNum: new Set(),  
  testString: new Set(),  
}

api를 직접 테스트 VS stub을 통한 테스트

api 요청 부분을 stub하는 방식은 여기에 정리했다.
공식문서와 코치님의 말에 의하면 api를 직접 테스트하는 방식과 stub하는 방식은 적용하는 기준이 다르다고 한다.
api를 직접 테스트하는 방식
- api 요청량에 제한이 없는 경우
- 팀내에서 api 서버를 구축한 경우
api 요청 부분을 stub하는 방식
- api 요청량에 제한이 있는 경우
- api 요청 후 돌아온 응답에 대한 후처리에 관한 테스트에 집중할 때
- 데이터를 mocking 해두면 api에 영향받지 않고, 비즈니스 로직만 중점적으로 테스트 가능하다.

상수를 Object.freeze() 이용해서 동결화 해야하는가?

상수를 직접 사용하는 사람들은 개발자이며, 대문자로 이름이 지어진 상수는 변경하지 않을 것이다.
따라서 객체 또는 배열의 상수의 값을 변경하는 거의 없을 것이고, 상수를 동결화할 필요도 없다.

고민과 질문 그리고 성장

이번 미션에서 리뷰어님께 드린 질문의 개수가 적었다. 이유에 대해서 생각을 해봤는데, 고민을 덜 해서 그런 거 같다. 잘 안되는 게 있으면 일단 차선책을 찾아서 해결했다. 그리고 리팩터링할 때 최선의 방법으로 고쳐보자고 생각했지만, 실행에 옮기지 않았다. 차선책이라는 쉬운 길로만 가다 보니 최선책으로 가기 위한 고민이 적었다. 고민이 적으니 그에 따라 질문도 적었다.
최근 코치님께 상담받으며 기억에 남는 말은 고민을 하는 게 당장 성과로 들어나진 않을 수 있지만, 고민을 많이 해본 크루는 나중에 더 많이 성장해있다. 이다. 이 말을 듣고, 다른 크루들의 pr을 보니 고민이 무엇이고 리뷰어님과 티키타카하면서 고민을 해결하는 과정이 눈에 보였다.
고민한 만큼 성장한다!라는 마음에 새기며, 다음 미션에서는 최선책을 찾기 위해 고민하는 시간을 더 갖도록 해야겠다.

[Cypress] Api test stub 하기 with intercept

w00se — Thu, 17 Mar 2022 01:29:43 +0900

cypress의 Network Requests

intercept 메서드를 활용하면 Api 요청 부분을 stub할 수 있다.

사용 예시: api 요청부분을 stub으로 처리하고 응답 결과로 dummy 데이터 반환하기
- 'https://abcd.efg.com/*'을 사용하면 url host가 abcd.efg.com으로 시작하는 모든 요청에 대한 응답을 stub한다.
- 공식문서에 의하면 아래 예시처럼 fixture를 단축해서 사용할 수 있다.
```
cy.intercept('https://abcd.efg.com/*', { fixture: 'dummyData.json' }).as('requestData');
cy.wait('@requestData');
```

[Cypress] viewport 크기 조절하기

w00se — Wed, 16 Mar 2022 22:00:13 +0900

cypress viewport 크기 조절하기

왜 필요한가 ?

cypress의 기본 viewport 크기는 1000px X 660px이다.
만약 테스트하려는 서비스의 엘리먼트 스타일이 해당 viewport의 크기보다 크다면, 예상치 못하게 테스트 실패할 수 있다.
예시: dimmed 영역 클릭 시 모달이 닫히는지 확인하는 테스트

[viewport 크기 조절 전]

viewport의 크기를 조절하지 않으면 모달의 dimmed 영역이 보이지 않아, 테스트가 원활하게 진행되지 않는다.

[viewport 크기 조절 후]

성공!

방법

cy.viewport() 메서드를 이용하는 방법
cypress.json 파일에 viewport의 크기를 설정하는 방법

예시

// cypress.json
{ 
  "viewportWidth": 1920,
  "viewportHeight": 975
}

읽어 주셔서 감사합니다 :)
잘못된 부분이 있다면 댓글로 편히 알려주세요

[우아한 테크코스] 행운의 로또 미션 회고

w00se — Mon, 14 Mar 2022 00:58:04 +0900

https://pixabay.com/ko/photos/글쓰기-작가-메모-펜-공책-923882

webpack 기본기를 공부하기 시작!

웹팩을 공부하고 사용한 경험이 이번 미션의 가장 큰 수확이라고 생각합니다.
webpack의 CleanWebpackPlugin를 사용하면서 output path를 잘못 설정해서 .git 디렉터리가 삭제되는 경험을 했습니다.
- 실패는 성공의 어머니라고 하듯이, 해당 경험이 webpack을 공부하는데 계기가 됐습니다.
- 디렉터리가 삭제됐다면 mac 기준으로 cmd + z를 시도해 볼 필요가 있습니다.(저는 침착하지 못했고, 결국 다시 처음부터 작업을 시작했습니다.)
웹팩에 대해서는 블로그의 게시글로 간략히 정리를 했습니다.

랜덤 테스트에 대해서

랜덤은 테스트하기 힘들다라는 말을 자주 들었는데, 막상 랜덤과 관련 있는 테스트 코드를 작성할 때 어떤 식으로 테스트 코드를 작성할지 감이 잘 오지 않았습니다.
- 예를 들면 이번 미션에서 하나의 로또는 1 ~ 45 사이의 6개의 숫자를 랜덤으로 이루어져있다.라는 기능을 구현한 후 테스트를 어떤 방식으로 진행할지 명확하지 않았습니다.
코드 리뷰를 통해 알게 된 점은 아래와 같습니다.

랜덤 값 자체는 테스트할 수 없다. 즉, 랜덤으로 생성하는 값의 범위를 테스트하는 건 적절하지 않다.
그러나 반환되는 데이터 형식(데이터의 길이 또는 중복 여부)는 테스트할 수 있다.

vscode extension을 활용해서 오타 예방하기

이번 미션에서 유독 오타가 많았습니다.
해당 extension을 활용하면 어느 정도 오타를 방지할 수 있습니다.

트리 쉐이킹 키워드에 대해서

이번 미션에서 lodash를 처음 사용해봤는데, 피드백 받기 전에는 아래의 예시 코드처럼 lodash의 모든 메서드를 가져오는 방식으로 코드를 작성했습니다.

import * as _ form 'lodash';

하지만 위 예시처럼 코드를 작성하면 사용하지 않는 메서드들도 모두 import하여 번들링 시 파일의 크기가 커진다는 사실을 배웠습니다.
따라서 번들 파일의 크기를 최적화하기 위해서 필요한 메서드만 불러오는 습관이 필요하며 이는 트리 쉐이킹과 관련이 있다는 것을 알게 됐습니다.
트리 쉐이킹에 대해서 이 글을 보면서 공부했습니다.

조건문은 부정문보다는 긍정문으로

부정문보다는 긍정문이 읽는 사람에게 더 잘 읽힌다고 합니다.

커스텀 이벤트

이번 미션에서 커스텀 이벤트에 대해서 처음 접했습니다.
커스텀 이벤트는 MVC 패턴에서 Controller와 View의 의존성을 끊기 위해 사용된다고 합니다.

[javascript] scroll event 사용해보기 with throttle 기법

w00se — Wed, 9 Mar 2022 11:59:11 +0900

throttle 기법

일정 시간동안 발생한 이벤트를 한번만 처리하는 방법
- 에를 들어 throttle을 활용하면 1총 동안 이벤트가 여러 번 발생해도 이벤트 내부 함수는 1번만 실행할 수 있게 구현 가능합니다.
scroll 이벤트와 연속적으로 호출되는 이벤트를 처리할 때 유용합니다.

let timerId;

const handleToDoListScrollEvent = (e) => {
  // 스크롤이 맨 아래 쪽에 있지 않으면 early return
  if (e.target.offsetHeight + e.target.scrollTop < e.target.scrollHeight) {
    return;
  }

  // timerID가 Truthy한 값이면 early return
  if (timerId) {
    return;
  }

  timerId = setTimeout(() => {
    timerId = null;

    console.log(
      '스크롤 이벤트 발생',
      e.target.scrollHeight,
      'scrollTop: ',
      e.target.scrollTop,
      'offsetHeight: ',
      e.target.offsetHeight
    );
  }, 1000);
};

// $toDOWrapper은 id가 #to-do-wrapper인 div 태그
const $toDoWrapper = document.querySelector('#to-do-wrapper');

$toDoWrapper.addEventListener('scroll', handleToDoListScrollEvent);

참고 자료
mdn web docs - scroll

읽어 주셔서 감사합니다 :)
잘못된 부분이 있다면 댓글로 편히 알려주세요.

[javascript] dotenv 사용해보기 with webpack

w00se — Tue, 8 Mar 2022 23:19:34 +0900

dotenv란?

.env라는 파일에서 변수를 불러와서 process.env에 변수를 삽입해주는 패키지
웹팩의 DefinePlugin과 함께 사용하면, 빌드된 파일에 환경 변수를 주입할 수 있다.

설치

npm install --save dotenv

활용법

프로젝트의 root 디렉터리에 .env 파일 생성 후 환경 변수 선언

// .env
API_KEY="123"

webpack.config.js 파일에서 DefinePlugin 설정

// webpack.config.js
require('dotenv').config();

module.exports = {
  ...
  plugins: [
    ...
    new webpack.DefinePlugin({
      // .env 파일의 API_KEY 값을 API_KEY 환경 변수로 삽입
      API_KEY: JSON.stringify(process.env.API_KEY),
    }),
    ...
  ],
  ...
};

환경 변수 사용하기

// index.js
console.log(API_KEY) // "123"

참고 자료
DaleSeo: dotenv로 환경 변수 관리하기

읽어 주셔서 감사합니다 :)
잘못된 부분이 있다면 댓글로 편히 알려주세요