npm을 사용한다면 package-lock.json, yarn을 사용한다면 yarn.lock 파일을 본적이 있었을 것이다. 나도 이 파일을 꽤나 오랫동안 봤지만 정확히 왜 만들어지고 어떻게 사용되는지에 대해서 잘 모르고 있기에 이번 기회에 제대로 공부하고 넘어가기로 했다.

왜 만들어지는 것인가?

version range

package-lock.json은 잘 몰라도 package.json은 잘 알 것이다. 우리는 모듈을 설치하고 설치된 모듈의 정보들을 package.json에서 확인한다. 하지만 모듈의 버전은 package.json에 상세히 적혀있지 않아도 된다. package.json에서는 모듈의 버전 정보를 저장할 때 version range를 사용할 수 있기 때문이다. version range는 정확하게 1.0.12 버전을 사용할 것이라고 기입하는게 아닌 1.0.12 버전 이상을 사용할 것이라고 범위를 지정하는 버전 정보 기입 방식이다. 그렇다면 왜 명확하게 기입하지 않고 범위를 통하여 기입하는 것일까? package.json에 패키지 버전을 명확하게 기입하면 패키지의 버그가 수정이 되어도 업데이트가 되지 않아 package.json에 적힌 버전을 손수 수정해야하기 때문이다.

package-lock.json

이제는 왜 package-lock.json이 생겨났는지는 눈치를 챌 수 있을 것이다. 바로 사용하는 모듈의 버전을 명확하게 관리하기 위해 package-lock.json 파일이 생겨났다. 모듈을 version-range로만 관리를 하게된다면 같은 프로젝트를 하는 개발자의 컴퓨터들 안에 모두 다른 버전의 모듈이 설치될 가능성이 있다. 설치된 버전이 다르다면 지원하는 기능도 차이가 생겨 프로덕트에 에러를 초래할 가능성이 크다.

언제 만들어지나?

npm 공식문서에 따르면, package-lock.json은 npm이 node_modules 트리 또는 package.json을 수정하는 모든 작업에 대해 자동으로 생성된다고 한다. 그리고 package-lock.json이 생겨난 이후에는 중간 종속성 업데이트에 관계없이 후속 설치에서 동일한 트리를 생성할 수 있도록 생성된 정확한 트리를 활용한다고 한다. 추가적으로 이 파일은 소스 리포지토리에 커밋하기 위한 것라고 설명하고 있다.

정리

package-lock.json 파일은 package.json 파일에서 모듈들의 버전을 범위로 기입하기 때문에 프로젝트에서 사용하고 있는 정확한 버전을 관리하는 파일이다. 가끔 package-lock.json 파일에 익숙치 않다보니 깃에 올려 관리해야하는지 고민하는 분들이 있었는데 무조건 올려야합니다~!!!!

SWR을 사용했을 때 여러 이점이 있겠지만 이 글에서는 SWR의 컨셉과 Next JS의 Pre-Render와 어떻게 페어링 하는지에 대해서 다루도록 하겠습니다.

stale-while-revalidate

"SWR"이라는 이름은 HTTP RFC 5861에 의해 알려진 HTTP 캐시 무효 전략인 stale-while-revalidate에서 유래되었습니다. -SWR 홈페이지-

SWR의 이름의 유래는 stale-while-revalidate에서 왔다고 한다. 그렇다면 stale-while-revalidate은 무엇일까? stale-while-revalidate은 Cache 제어 방법 중에 하나다. 웹 개발자는 주로 HTTP를 사용하여 서버와 클라이언트가 데이터를 주고받는다. 데이터를 주고 받다가 요청과 응답하는 리소스가 매번 같은 경우 필요없는 통신 리소스를 줄이기위해서 Cache를 활용한다.

Cache: 이전의 응답 리소스의 복사복을 저장하고 있다가 요청 시에 복사복을 제공하는 기술

Cache는 클라이언트와 가까이 있어 서버와 직접 데이터를 주고 받는 것보다 더 빠르게 결과를 보여줄 수 있다. 그리고 서버에 요청을 줄여 서버의 부하를 줄여줄 수 있으며 네트워크 트래픽을 줄여줄 수 있다.

HTTP는 이러한 Cache를 제어할 수 있는 여러가지 방법이 있는데 그것을 Cache-Control이라고 하며 그 중 하나가 stale-while-revalidate다. 다른 여러가지 Cache-Control은 MDN 문서에서 확인이 가능하며 이 글에서는 그 중에 stale-while-revalidate과 max-age를 비교해가며 알아보겠다. 우선 max-age는 Cache의 유효기간을 설정할 수 있다. 해당 유효기간 동안은 Cache를 업데이트 하지않고 재사용한다. stale-while-revalidate도 기간을 설정 할 수 있는데 max-age의 유효기간과는 다르다. stale-while-revalidate의 기간동안은 요청시 이전 캐시 데이터를 즉시 사용하지만 비동기적으로 데이터 통신을 하여 업데이트를 진행한다. SWR은 이와같은 방식으로 데이터 통신의 부하를 조절한다.

사용 사례

stale-while-revalidate는 max-age와 같이 사용된다. 두가지 옵션에 시간(초)를 설정하여 사용한다. 예를 들어 max-age=1; stale-while-revalidate=59;로 설정을 했다고하자. 1초 이내에 HTTP 요청이 다시 들어온다면 max-age 이내이므로 지금 갖고 있는 Cache가 최신이라고 판단하므로 Cache 데이터를 재사용한다. 1초 이후 60초 이내에 HTTP 요청이 들어온다면 캐시된 값은 오래되었지만 캐싱된 값을 반환한다. 그리고 백그라운드에서 향후 사용을 위한 캐시를 새로운 값으로 채우도록 재검증 요청이 이루어지게 된다. 60초 이후에는 캐싱된 데이터를 사용하지 않고 서버에 요청하여 받은 응답을 사용한다.

with Next JS (feat. Pre-Render)

SWR은 SWRConfig의 fallback 옵션을 사용하여 Next JS의 SSR과 SSG와의 호환성을 높일 수 있다.

예시 코드

// getStaticProps 혹은 getServerSideProps
export async function getStaticProps () {
  const article = await getArticleFromAPI()
  return {
    props: {
      fallback: {
        '/api/article': article
      }
    }
  }
}

function Article() {
  // `data`는 `fallback`에 있기 때문에 항상 사용할 수 있습니다.
  const { data } = useSWR('/api/article', fetcher)
  return <h1>{data.title}</h1>
}

export default function Page({ fallback }) {
  // `SWRConfig` 경계 내부에 있는 SWR hooks는 해당 값들을 사용합니다.
  return (
    <SWRConfig value={{ fallback }}>
      <Article />
    </SWRConfig>
  )
}

위와 같이 SWR을 사용하여 SSR 혹은 SSG같은 Pre-Render와 호환을 할 수 있다. Pre-Render에서는 SWR이 아닌 axios 또는 fetch를 활용하여 데이터 패칭을 하여 props로 데이터를 넘겨준다. 넘겨 받은 데이터를 SWRConfig의 fallback에 설정해주면 Pre-Render에 손쉽게 데이터를 넘겨줄 수 있다.

정리

이 글을 쓰며 SWR의 컨셉과 Next JS와의 페어링이 왜 좋은지에 대해서 알아봤다. 이전에는 단순히 편하다는 느낌만 갖고 사용하였지만 SWR의 컨셉을 통해 왜 SWR이 다른 데이터 패칭 라이브러리에 비해 편하다고 느껴졌는지 알 수 있었다. 그리고 아직은 사용해본적은 없지만 SWR과 동일한 stale-while-revalidate를 주요 컨셉으로 갖고 있는 React Query에 대해서도 많은 정보를 접하게 되었고 흥미가 생기게 되었다. 만약 React Query에 대해서 궁금증이 생긴다면 이 링크(React query 공식 페이지)에 들어가 다른 데이터 페칭 라이브러리와 비교한 표를 확인하고 좀 더 자세히 SWR과 비교된 글을 원한다면 이 블로그 글을 추천한다. 나는 위 글들을 읽고 React Query에 대해 궁금증이 생겨서 다음 프로젝트에서는 React Query를 사용할 것 같다. React Query를 직접 사용하고나면 사용하며 느낀 SWR과 React Query를 비교하는 글로 돌아오겠다.

롱프레스 이벤트란 말이 익숙치 않은 사람들이 많을 것이다. 하지만 설명을 듣는 순간 모두들 아 그거~라고 할 것이다. 롱프레스 이벤트란 터치 홀드라고도 불린다. 한 요소를 길게 누르고 있는 이벤트다. 우리가 보통 핸드폰에서 앱을 지우기위해 메뉴를 띄우거나 이동하게 하기 위해서 길게 누르는 그 액션을 롱프레스라고 한다. 스마트폰이 익숙한 우리에게는 이 이벤트가 익숙하지 않을 수 없다.

보통 롱프레스 이벤트는 핸드폰의 앱아이콘들처럼 단순 터치를 할 때 이미 다른 기능이 있거나 혹은 자주 터치가 일어나는 요소에 새로운 이벤트 리스너를 넣고 싶을 때 많이 사용된다. 밑미 프로젝트를 할 때 우리는 댓글을 삭제/수정하거나 신고를 하기위한 모달을 띄워야했다. 모바일 사용을 위한 웹앱 구현이였기 때문에 댓글 요소에 많은 터치가 생길 수 밖에 없었기에 롱프레스 이벤트가 일어나면 모달을 띄우기로 결정했다.

구현 방법

우리는 롱프레스의 기준을 3초로 정했다. 3초동안 댓글을 누르면 해당 댓글에 대한 모달이 뜨게하고 만약 그전에 손을 땐다면 모달이 뜨지 않도록 구현했다.

모달이 뜨게하기 위해서 onTouchStart가 일어난다면 setTimeout API를 활용하여 3초 이후에 함수가 실행되도록 예약을 했다. 그리고 모달이 뜨지 않도록하기 위해서는 onTouchEnd가 일어났을 때 clearTimeout API를 사용하였다. 이러한 과정에서 해당 타겟 요소와 timeout API를 기억하기 위해서 useRef를 활용하였다.

위의 코드는 롱프레스 이벤트 리스너 기능을 커스텀 훅으로 만든 결과물이다.

// useLongPress.ts
import React, { useCallback, useRef } from 'react';

const useLongPress = (
  onLongPress: () => void,
  { delay = 300 } = {},
) => {
  const timeout = useRef<NodeJS.Timeout>();
  const target = useRef<HTMLElement>();

  const start = useCallback(
    (event) => {
      if (event.target) {
        event.target.addEventListener('touchend', preventDefault, {
          passive: false,
        });
        target.current = event.target;
      }
      timeout.current = setTimeout(() => {
        onLongPress();
      }, delay);
    },
    [onLongPress],
  );

  const clear = useCallback(
    () => {
      if (timeout.current) clearTimeout(timeout.current);
      if (target.current) {
        target.current.removeEventListener('touchend', preventDefault);
      }
    },
    [],
  );

  return {
    onTouchStart: (e: React.TouchEvent) => start(e),
    onTouchEnd: () => clear(),
  };
};

const isTouchEvent = (event: TouchEvent) => 'touches' in event;

const preventDefault = (event: TouchEvent) => {
  if (!isTouchEvent(event)) return;

  if (event.touches.length < 2 && event.preventDefault) {
    event.preventDefault();
  }
};

// targetComponent.tsx
...
const { onMouseDown, onMouseLeave, onMouseUp, onTouchEnd, onTouchStart } =
    useLongPress(() => funtion());
...
<div
  onTouchEnd={onTouchEnd}
  onTouchStart={(e) => onTouchStart(e)}
>
  타겟 요소
</div>

정리

단순히 기능만 보면 간단하게 구현이 될 것이라고 생각했지만 생각보다 복잡했었다. 해당 글에서 다루지는 않았지만 여러 댓글 중에 어떤 댓글을 위한 모달인지 확인을 하기위해서 댓글 데이터를 따로 저장하는 기능을 추가 구현하여 원하던 기능을 완성하였다. 많은 생각을 하고 많은 에러를 만나면서 구현했던 기능 중 하나였고 매우 유용하게 사용하였다.

WYSIWYG는 What You See Is What You Get, "보는 대로 얻는다"라는 문장의 줄임말이다. 문서를 편집하는 과정에서 화면에 보이는 문장이나 글 맵시 등을 동일하게 화면에 출력해주는 방식이다. 위지위그 에디터는 이러한 기능을 위해서 사용자는 모르게 <p>, <span>, <em style=> 등 다양한 HTML 소스를 입력해주고 있다.

프로젝트를 하다보면 단순 input이나 textarea로는 부족한 경우가 많다. 예를 들면 블로그 글을 작성할 때나 쇼핑몰에 제품 설명을 적어야 하는 경우를 떠올리면 이해가 빠를 것이다. 잘 구현을 한다면 충분할 수도 있지만 위지위그 방식이 아니라면 사용자 입장에서 내가 쓴 글이 어떻게 출력이 되는지 확인 후에 다시 수정을 하는 번거로운 과정이 추가된다. 그래서 이번 프로젝트에서 위지위그 에디터를 활용하게 되었다.

TinyMCE 선택한 이유

시중에는 정말로 많은 WYSIWYG 에디터가 존재하기 때문에 우리는 TinyMCE를 선택하기 위한 몇가지 조건을 만들었다. 우선 UI 커스터마이징에서 자유로워야할 것. 아무리 이쁜 디자인, 좋은 기능의 에디터여도 우리가 만들 사이트에 녹아들지 않는다면 사용할 수 없었다.

두번째, 무료 버전으로도 충분히 기능 구현이 가능할 것. 개발을 하다보면 기능이 추가되거나 줄어들거나한다. 그렇기 때문에 무료 버전이 지원하는 기능이 너무 타이트하다면 원치 않는 지출이 늘어나거나 최악의 경우 다른 에디터로 변경해야하는 일이 생길 수 있었다. 그렇기 때문에 무료 버전으로도 충분한 기능 구현이 되는지가 중요했다.

마지막으로는 지속적인 인지도였다. 인지도가 있다는 것에는 많은 의미가 포함되어 있었다. 사람들이 많이 사용을 했고 그에 대한 참조 문서가 많았으면 했다. Docs에도 충분한 설명이 있지만 가끔은 필요한 기능을 구현하기 위해서 Docs에 없는 방식으로 구현을 해야할 때도 있었다. 그리고 지속적으로 많은 사람들이 사용하고 있다는 것은 많은 사람들이 많은 실험 혹은 개발 경험을 거쳤을 것이라는 의미라고 생각되었다.

TinyMCE 이외에도 CKeditor, Trix, Summernote, Draft.js 등 많은 에디터들이 후보에 올랐었다. 하지만 결국 위 모든 조건을 가장 넉넉하게 통과한 에디터는 TinyMCE였다.

TinyMCE 커스텀하기

기본 스타일 커스텀

TinyMCE는 기본적인 UI 옵션을 제공한다. 해당 옵션들은 TinyMCE docs에서도 설명이 잘 되어있느니 내가 사용했던 것들만 간단히 집고 넘어 가겠다.

우선 TinyMCE는 메뉴바와 툴바 모두 제공한다. 하지만 우리의 경우 툴바만 필요했기에 menubar: false,를 추가하여 메뉴바는 보이지 않게하였다.

그리고 툴바를 제공하는 것뿐만 아니라 내부 요소들을 원하는 것들로만 원하는 위치에 원하는 것들끼리 묶을 수 있게 커스터마이징이 가능하다. toolbar: 'undo redo | bold italic underline', 이와 같이 원하는 버튼의 키워드를 string 형식으로 적어주고 |기호를 사용하여 나눠주면 툴바 버튼들 사이에 보더가 생긴다.

그리고 좀더 깔끔한 UI를 위해서 상태바를 삭제하였다. 현재 상태를 알 수 있지만 디자인적으로 지저분해보였다. statusbar: false, 이 옵션을 false로 두면 상태바를 없앨 수 있다.

TinyMCE에서 제공하지 않는 스타일 커스텀

우리는 TinyMCE의 디자인을 좀더 세세하게 커스텀하기를 원했다. 툴바 버튼 사이의 보더의 굵기나 색을 변경한다거나 툴바 버튼의 크기를 바꾸거나 TinyMCE 전체 보더를 안보이게 하거나 등등.

우리 팀은 TinyMCE를 처음 써봤기 때문에 이 문제를 어떻게 해결할 수 있는지 몰랐기에 Docs를 탈탈 털었지만 결국 Docs에서는 해당 기능을 찾지 못하였다. 위처럼 TinyMCE가 제공하는 옵션으로 커스터마이징이 되었다면 좋았겠지만 그렇지 않았던 것이다. 결국 TinyMCE에 스타일을 !important로 주는 것으로 해결했다. TinyMCE의 소스 코드를 보면 자체적으로 class명이 설정되어있다. 우리가 원하는 요소의 class명을 찾아 직접적으로 스타일링을 해주었다.

// Emotion 코드입니다.
& .tox-toolbar__group {
    border-color: #F9F5F3 !important;
  }

이미지 모달 버튼 + 이미지 삽입

게시물에는 글뿐만 아니라 이미지도 넣어야 때가 많다. 우리 프로젝트에서도 이미지를 넣어야했었고 TinyMCE에서 이미지 플러그인과 UI를 제공해준다. 하지만 문제는 제공해주는 이미지 선택 UI가 이쁘지 않았다.

그래서 직접 디자인한 모달을 사용하여 이미지를 삽입하기로 결정했다. 여기서 두가지 기능이 필요하다. 우선 TinyMCE의 버튼을 활용하여 모달을 켜고 끄는 것과 외부 모달을 이용하여 이미지를 TinyMCE 에디터 안에 삽입하는 기능이다.

툴바 버튼 만들기

TinyMCE는 툴바 또는 메뉴바 버튼을 새롭게 만들 수 있다. 우리는 툴바 버튼을 생성하여 해당 버튼을 모달에 연결해주었다.

<Editor
  init={{
    toolbar: 'custom_button',
    setup: (editor) => {
      editor.ui.registry.addButton('custom_button', {
      icon: 'image',
      onAction: () => setIsShowModal(true),
      });
    },
  }}
/>

위의 toolbar의 custom_button은 TinyMCE에서 제공해주는 옵션이 아니다. 우리가 새롭게 생성할 버튼이다. toolbar에서 설정 후 setup에서 위와 같이 버튼을 만들어주면 된다.

editor.ui.registry.addButton()의 경우 두가지 인자를 받는다. 첫번째는 버튼 이름이다. toolbar에서 미리 설정해놓은 이름을 적어주면 된다. 두번째는 객체로 되어있고 객체에는 버튼에 필요한 요소들을 설정할 수 있다. 위처럼 해당 객체에 icon에 기존에 TinyMCE에서 제공해주는 아이콘명을 적어줘도 되고 이미지를 따로 임포트해줘도 괜찮다. 그리고 onAction 안에 해당 버튼이 어떤 동작을 할지 설정하면 툴바 버튼 만들기는 마무리된다.

이미지 삽입하기

이미지 삽입하기는 간단하다. 하지만 예제가 모두 바닐라 JS용 예제만 존재해서 방법을 찾는데 오래걸렸다. TinyMCE 자체도 하나의 textarea이기 때문에 내용을 useState로 관리를 한다.

 setState((state) => state+<img src="이미지 경로" />);

위 코드로 간단하게 이미지를 삽입 가능하다.

TinyMCE 설정 추상화

TinyMCE 에디터를 처음 글을 등록할 때도 사용하지만 이미 쓴 글을 수정할 때도 에디터가 필요했다. 수정페이지에서 사용해야하는 재사용성의 문제도 있지만 커스텀을 많이 하다보니 설정을 위한 코드가 점점 길어졌고 해당 코드를 JSX의 HTML부분에 넣었을 때 파일 구조를 보기 힘들어져서 설정 코드를 따로 추상화하기로 결정했다.

// config.ts
export const EDITOR_CONFIG = {
  id: 'tinyEditor',
  init: {
    menubar: false,
    statusbar: false,
    ...설정
  },
};

// EditorContainer.tsx
...
<Editor
  {...EDITOR_CONFIG}
/>;
...

위의 코드처럼 EDITOR_CONFIG 코드를 따로 추상화하여 불러와서 사용하였다.

마무리

이 글에서는 TinyMCE 위지위그 에디터를 사용해보며 커스터마이징한 경험에 대해 작성했다. 기본 설정이나 TinyMCE에서 제공하는 커스터마이징은 Docs에도 잘 나와있지만 Docs에 나와있지 않은 것들도 충분히 자유롭게 커스터마이징이 가능했기 때문에 만족감이 매우 높았다.

많은 분들이 프로젝트에 위지위그 에디터를 사용할텐데 안정적이고 무료 버전으로도 충분한 기능 구현이 가능하며 커스터마이징이 자유로운 에디터를 찾는다면 TinyMCE를 추천한다.

많은 서비스에 이미지 업로드 기능이 들어간다. 내가 이전 프로젝트들에서 이미지를 업로드했었다. 하지만 업로드할 이미지 미리보기 기능은 필수는 아니였다. 이미지를 제대로 서버에 올리고 나중에 제대로 받아오는 것이 더 중요하다. 하지만 사용자가 내가 올릴 이미지가 어떤 것인지 확인하고 잘못올렸을 경우 다른 이미지로 대체할 수 있도록 한다면 더 나은 사용자 경험을 줄 수 있다. 그래서 많은 서비스들이 이미지 미리보기 기능을 거의 필수로 구현한다.

이번 프로젝트에서는 이미지 미리보기 기능을 필수로 구현하게 되었다. 해당 기능을 구현하기 위해 여러가지 이미지 미리보기 기능을 구현할 수 있는 방법을 찾아보게 되었고 찾아보며 생각한 것들을 정리하게 되었다.

이미지 미리보기 구현 방법 비교

이미지 서버에 올린 후에 보여주기

이미지를 미리보기를 구현하는 여러가지 방법이 있다. 첫번째는 이미지 서버에 올리고 반환된 이미지 주소를 활용하여 보여주는 것이다. 이 경우 몇가지 문제가 있다. 우선 이미지 서버에 이미지를 올리는데 꽤나 시간이 걸린다. 그렇기 때문에 이미지를 선택한 후 이미지를 화면에 띄우기까지 시간 틈이 있어 사용자가 느끼기에 즉각적이지 않다. 만약 여러번 이미지를 교체하게 된다면 대기시간의 불편함은 더 커지게 될 것이다. 두번째는 이미지를 올릴 때마다 서버에 저장되는 이미지가 생기기 때문에 이미지 서버의 비용이 당연히 늘어날 수 밖에 없다. 개인 프로젝트라면 큰 차이가 없겠지만 많은 사람들이 사용하는 서비스라면 엄청난 금액이 지불될 수 있다.

FileReader

구현 방법

이미지 서버와 통신하지 않고 이미지 미리보기를 구현하는 방법으로는 크게 두가지가 있다. 바로 FileReader와 createObjectURL이다. 그중 FileReader를 활용한 구현 방법 먼저 확인해보자.

// JS
const [imgSrc, setImgSrc] = useState('');

const encodeFileToBase64 = (fileBlob) => {
  const reader = new FileReader();
  reader.readAsDataURL(fileBlob);
  return new Promise((resolve) => {
    reader.onload = () => {
      setImgSrc(reader.result);
      resolve();
    };
  });
};

// HTML(input)
<input
  type="file"
  onChange={(e) => {
    encodeFileToBase64(e.target.files[0]);
  }}
/>

위의 encodeFileToBase64함수는 다음과 같이 진행된다.

• FileReader의 인스턴스(reader)를 생성한다.
• 인자로 받아온 fileBlob을 base64 포맷으로 인코딩한다.
• 인코딩이 마무리되면 reader.result 안의 문자열을 imgSrc에 저장한다.
• resolve를 호출하여 Promise가 이행상태가 된다.

FileReader의 특성

• FileReader의 경우 IE10을 포함한 모든 모던 브라우저를 지원한다.
• 많은 메모리를 사용하고 해당 메모리를 우리가 지울 수 없다. 가비지 컬렉터에 의해 자동으로 지워지게 된다.
• 이미지를 띄우는데 즉각적이지 않고 약간의 시간이 걸린다.

createObjectURL

구현 방법

마지막으로 내가 선택한 createObjectURL이다.

// JS
const [imgSrc, setImgSrc] = useState('');

const saveFileImage = (fileBlob) => {
  const fileUrl = URL.createObjectURL(fileBlob);
  setImgSrc(fileUrl);
};

// HTML(input)
<input
  type="file"
  onChange={(e) => {
    saveFileImage(e.target.files[0]);
  }}
/>

코드를 보면 훨씬 간결해졌다. saveFileImage함수는 다음과 같이 진행된다.

• URL.createObjectURL을 사용하여 인자로 받아온 fileBlob을 가리키는 URL을 DOMString으로 만들어준다.
• 만들어진 URL을 imgSrc에 저장한다.

revokeObjectURL을 활용한 객체 URL 해제

createObjectURL을 활용한 방식은 같은 객체를 사용하더라도, createObjectURL()을 매번 호출할 때마다 새로운 객체 URL을 생성한다. 그렇기 때문에 생성된 객체 URL을 직접 하나씩 해제해주어야한다.

URL.revokeObjectURL(objURL);

objURL을 해제해주는 방법은 간단한다. 위처럼 해제하려는 objURL URL.revokeObjectURL() 함수 안에 넣어서 호출하면 된다.

createObjURL 특성

• createObjectURL은 IE10을 포함한 모든 모던 브라우저를 지원한다.
• 해시가 포함된 URL을 반환한다.
• document의 언로드 이벤트가 일어나거나 직접 revokeObjectURL을 실행하지 않으면 메모리가 남아있게된다.
• 이미지를 즉각적으로 띄울 수 있다.

마무리

위에서 이미지 미리보기를 구현 할 수 있는 여러가지 방법을 소개했다. 여러가지 방법을 소개했지만 앞선 두가지 방법은 장점보다 단점이 많았기 때문에 createObjectURL 방식을 추천한다.

GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼입니다. 레포지토리에 대한 모든 풀 요청을 빌드 및 테스트하는 워크플로를 생성하거나 병합된 풀 요청을 프로덕션에 배포할 수 있습니다. GitHub Actions는 단순한 DevOps를 넘어 리포지토리에서 다른 이벤트가 발생할 때 워크플로를 실행할 수 있도록 합니다. 예를 들어, 누군가가 저장소에 새 문제를 생성할 때마다 적절한 레이블을 자동으로 추가하는 워크플로를 실행할 수 있습니다. -GitHub 홈페이지-

깃헙에서는 GitHub Actions를 위와 같이 설명하고 있다. 쉽게 얘기하면 깃헙에서 특정 이벤트가 발생했을 때 어떤 동작을 할지 설정해놔서 리액션을 자동화하는 서비스라고 생각하면 편할 것이다. 우리가 사용할 리소스를 순수 개발에 더 신경쓸 수 있게된다.

GitHub Actions 적용

나는 주로 3가지의 설정을 많이 사용한다. 3가지 모두 Pull request를 날렸을 때의 액션이 일어난다. 린트 확인, 빌드 테스트, 배포이다. 이 세가지를 사용하여 CI/CD를 자동화하여 사용한다. GitHub Actions 파일들은 .github/workflows 폴더에서 관리해주면된다.

린트 확인

우선 전체 코드를 보여주고 한줄씩 설명하도록 하겠습니다.

name: Lint check 

on: pull_request

jobs:
  build-test:
    name: Next Lint test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '16'
      - run: npm i -g yarn
      - run: yarn
      - run: yarn lint

• 우선 첫 줄의 name은 위크플로우의 이름이다. 위 값은 다른 워크플로우와 겹치지 않게 사용해야한다.

• on에서는 레포지토리의 어떤 이벤트를 감지할 것인지 설정해야한다. 위에서는 pull_request를 사용했지만 push를 사용하거나 특정 브랜치, 태그, path에서 작동하도록 설정이 가능하다.

• 그 다음은 jobs에 관련된 설정이다. name에서 job의 이름을 설정해주고 runs-on에서 어떤 환경에서 사용할지 설정이 가능하다. steps에서는 이제 어떤 일을 해줄지에 대해서 설정을 할 수 있다. Github 마켓플레이스에 올라온 액션의 사용도 가능하고 shell script 실행도 가능하다. 누군가 만들어 놓은 액션을 사용할 때는 uses를 사용해야한다. 그리고 with를 사용하여 액션에 값을 전달할 수도있다. 위의 코드는 node-version이 16이라는 의미다. shell script를 실행할 때는 run 키워드를 사용하면된다. 우리는 npm i -g yarn, yarn, yarn lint 명령어를 실행 시켰다.

빌드 테스트

name: Build test

on: pull_request

jobs:
  build-test:
    name: Next build test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '14'
      - run: npm i -g yarn
      - run: yarn
      - run: yarn build

위의 린트 확인 코드와 거의 동일하며 run에 yarn build 코드만 다르다.

Vercel 배포

GitHub Actions로 Vercel 배포도 자동화가 가능하다. 이 부분도 코드를 먼저 확인한 후 설명을 진행하겠다.

name: Deploy CI
on:
  push:
    branches: [main]
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  deploy:
    runs-on: ubuntu-latest
    if: "!contains(github.event.head_commit.message, '[skip ci]')"
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Deploy to Vercel Action
        uses: BetaHuhn/deploy-to-vercel-action@latest
        with:
          GITHUB_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
          VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
          VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
          VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

Vercel 배포는 다른 액션들과는 다르게 push 옵션에 브랜치가 설정이 되어있다. main 브랜치에 푸시할 때만 진행된다. pull_request에서는 타입 설정이 되어있다. pull_request가 위의 세가지 타입일 때만 해당 액션이 진행될 것이다.

jobs에 if 키워드를 사용하여 커밑 메시지에 skip ci가 포함되면 액션이 진행되지 않도록 설정되어 있다.

steps의 다른 키워드들은 이전에 봤지만 with 내부의 값들이 처음 보는 방식으로 값이 전달되고 있다. 위의 secret들이 어떻게 설정할 수 있고 위 값들은 어디서 가져와서 쓰는 것인지도 추가로 설명하겠다.

GitHub Secrets

Secrets의 설정은 간단하다. 원하는 레포지토리의 Settings>Secrets>Actions로 들어가면 된다. 들어가면 우측 상단의 New repository secret 버튼을 눌러서 설정하면 된다.

GITHUB_TOKEN

GitHub Token은 레포지토리가 아닌 오른쪽 위 프로필에서 Settings로 들어가야 발급이 가능하다.

• Settings>Developer settings>Personal access tokens에서 생성이 가능하다. 깃헙에 로그인이 되어있다면 이 링크로 접근이 가능할 것이다.

• 알맞은 페이지에 들어갔다면 우측 상단의 Generate new token 버튼을 눌러서 토큰을 생성하면된다. 토큰은 workflow 옵션 하나만 설정해주면 된다.

• 모든 설정 후 토큰을 만들면 토큰 값을 복사할 수 있게 나올 것이다. 해당 값을 복사하여 위의 GitHub Secrets에 들어가서 새 Secret을 만들면 된다.

VERCEL_TOKEN

이제는 Vercel token을 받으러 Vercel로 이동하여야한다.

• Vercel의 우측 상단의 프로필의 Settings>Tokens로 가면된다. 이것도 마찬가지로 Vercel에 로그인이 되어있다면 이 링크로 접근가능하다.
• 해당 페이지의 Tokens 섹션에서 Create 버튼을 눌러 토큰을 생성하고 SCOPE는 Full Account를 설정해주면 된다.

마찬가지로 생성된 토큰의 값을 GitHub Secrets에 Secret으로 저장하면 된다.

VERCEL_ORG_ID & VERCEL_PROJECT_ID

이 두개는 한번에 받아올 수 있다. 이 두개는 vercel CLI를 사용해서 받아올 수 있다.

• 우선 vercel을 깔아야한다.

  npm i -g vercel

• 이후 Vercel에 로그인을 진행해준다.

  vercel login

• 로그인이 다 되었다면 배포를 진행한다.

  vercel

  위의 과정이 끝나면 .vercel 폴더가 생긴다. 해당 폴더의 project.json파일을 보면 orgId, projectId가 있다. 이 값도 GitHub Secrets에 Secret으로 저장하면 모든 설정은 끝난다.

마무리

위의 세가지를 풀 리퀘스트에서 자동화해주면 배포 시에 생길 문제를 자동으로 체크가 가능해지고 문제가 없다면 배포까지 자동화가 진행된다. 개발을 하다보면 자동화에 대해서 항상 생각하게된다. 개발하는 것 이외에 리소스를 사용하는 것이 너무 아깝기 때문이다. 혹시 저와 같은 생각을 하고 있다면 이 기회에 GitHub Actions를 사용하시는 것을 추천합니다. 그리고 오늘 소개해드린 세가지 말고도 GitHub에서 확인해보면 정말로 많은 workflow가 만들어져있으니 한번 보셨으면 좋겠습니다.

GraphQL은 API용 쿼리 언어이자 기존 데이터로 이러한 쿼리를 수행하기 위한 런타임입니다. GraphQL은 API의 데이터에 대한 완전하고 이해하기 쉬운 설명을 제공하고, 클라이언트가 필요한 것을 정확하게 요청할 수 있는 기능을 제공하며, 시간이 지남에 따라 API를 더 쉽게 발전시키고 강력한 개발자 도구를 활성화합니다. -GraphQL 공식홈페이지

GraphQL은 우선 SQL과 마찬가지로 쿼리 언어이다. 하지만 그래프큐엘과 SQL의 사용성 측면에서 큰 차이가 있다. 우선 SQL은 데이터베이스에 저장된 데이터를 효율적으로 가져오는 것이 목적이지만, 그래프큐엘은 웹 클라이언트가 데이터를 서버로부터 효율적으로 가져오는 것이 목적이다. 그래서 SQL은 백엔드에서 작성 및 호출하지만 그래프큐엘은 클라이언트에서 작성하고 호출한다. 그렇기 때문에 그래프큐엘이 대체하는 것은 기존의 쿼리 언어들이 아닌 REST API이다.

그렇다면 프론트엔드에서 무엇이 불편했길래 메타(구 페이스북)는 그래프큐엘이라는 쿼리 언어를 만들었고 사람들은 그래프큐엘을 사랑하게 되었는지 알아보자.

2. GraphQL이 나오게 된 배경

기존의 REST API는 리소스와 URI를 조합하여 요청을 보내면 이에 대응하는 응답을 JSON이나 XML 형식으로 넘겨주었다. REST API의 가장 큰 강점은 예측 가능하고 일정한 정보와 작업을 요청하는 것이였다. 하지만 여기서 생기는 문제는 정해진 응답만을 받을 수 있다는 것이다. 예를 들어 A의 전화번호 정보를 받기위해서 A의 모든 정보를 받아야할 수 있다. 이렇게 필요없는 정보까지 받기 위해서 불필요한 리소스(시간, 통신비)가 생긴다.(Overfatching) 이러한 다른 모양의 다양한 요청과 응답이 필요한 서비스들이 많이 생겨났고 그로인한 리소스들을 줄이기 위해서 GraphQL이 각광받게 되었다.

REST API vs GraphQL

REST API는 URL과 METHOD 등을 조합하여 사용하기 때문에 필연적으로 많은 Endpoint가 존재한다. 하지만 그래프큐엘은 하나의 Endpoint만 존재한다. 그렇기 때문에 REST API에서는 각 Endpoint마다 데이터베이스 SQL 쿼리가 달라지지만 그래프큐엘은 스키마의 타입마다 데이터베이스 SQL 쿼리가 달라진다. 그러므로 위의 그림처럼 그래프큐엘은 네트워크를 여러번 호출(Underfatching)을 할 필요없이 쿼리 언어를 직접 작성하여 한번의 네트워크 호출로 원하는 데이터들을 받아올 수 있다.

3. GraphQL의 구조

3-1. Query 쿼리 / Mutation 뮤테이션

REST API의 경우에는 데이터 CRUD를 하기위해 get, post, put, delete를 사용하지만 GraphQL은 Query와 Mutation 두 가지만 사용한다. 데이터를 Read를 할 때는 Query를 사용하고 Create, Update, Delete를 하기 위해서 Mutation을 사용한다. 하지만 그래프큐엘 내부적으로 Query와 Mutation은 차이가 거의 없다. 그렇기 때문에 쿼리로 데이터를 수정할 수 있다. 그렇지만 변경을 발생시키는 작업은 명시적으로 뮤테이션를 이용해서 전송되어야 한다는 규칙을 지키는 것이 좋다.

Example

Query(요청 쿼리 / 응답 데이터)

위 그림과 같이 쿼리와 받은 데이터는 동일한 형태이다. 이렇게 명확하고 직관적인 응답 데이터를 받을 수 있는 이유는 그래프큐엘을 통해 서버가 클라이언트가 원하는 필드를 정확히 알 수 있기 때문이다.

Mutation(요청 뮤테이션 / 응답 데이터)

createReview 필드가 새로 생성된 리뷰의 stars 와 commentary 필드를 반환한다. 이는 하나의 요청으로 필드의 새 값을 변경하고 쿼리할 수 있기 때문에 기존 데이터를 변경하는 경우 특히 유용하다.

프래그먼트(요청 쿼리)

우리가 가져오려는 데이터의 형식이 너무 복잡하고 이 필드를 여러번 반복해서 사용해야한다면 우리는 프래그먼트를 사용할 수 있다. 프래그먼트 개념은 주로 복잡한 응용 프로그램의 데이터 요구사항을 작은 단위로 분할하는데 사용된다. 리액트에서 컴포넌트화하는 것을 연상하면 이해하기 쉬울 것이다.

3-2. Introspection 인트로스펙션

기존의 서버와 클라이언트의 협업 방식에서는 API 명세서를 주고 받는 절차가 필요하다.이러한 절차는 당연히 그에 맞는 리소스를 잡아먹게 된다. 만약 API 명세서를 제대로 업데이트하지 않는다면 그것은 큰 문제를 야기할 수 있다. 이러한 REST의 API 명세서 생성 자동화하는 것이 그래프큐엘의 인트로스펙션 기능이다. 그래프큐엘의 인트로스펙션은 서버에서 정의된 스키마의 정보를 생성 및 공유할 수 있게한다. 위 사진은 그래프큐엘 라이브러리에서 제공하는 플레이그라운드라고 불리는 쿼리용 IDE이다. 플레이그라운드에서 직접 쿼리 및 뮤테이션, 필드 스키마를 확인 할 수 있다. 물론 상용환경에서는 이러한 스키마의 공개한다면 보안 이슈가 존재한다. 그러므로 해당 기능을 끄는 옵션을 사용하여 상용환경에서는 끄는 것을 권장한다.

4. 정리

장점

• 그래프큐엘은 기존의 REST API가 필요한 데이터를 받기 위해서 여러번 요청을 보내야 했던 것(Underfetching)을 한번의 요청으로 받아올 수 있다.
• 필요하지 않은 데이터까지 포함된 데이터 덩어리를 받아오지(Overfetching) 않고 원하는 데이터만 선택적으로 받아올 수 있다.
• 가장 큰 장점은 인트로펙션 기능을 통해서 API 명세의 공유가 자동화 된다는 점이다. 이 부분은 개발의 생산성이 향상되어 백엔드 - 프론트엔드의 협업이 더 쉬워질 것이다.

단점

• File 전송 등 Text 만으로 하기 힘든 내용들을 처리하기 위해서는 외부 서비스에 의존하거나 복잡해진다.
• 고정된 요청과 응답만 필요할 때는 Query 요청의 크기가 REST API 보다 더 커진다.

마무리

오늘 알아본 결과 그래프큐엘은 매우 훌륭하고 좋은 언어이자 서비스지만 만능은 아니다. 어떤 정보를 제공하느냐에 따라 REST API와 그래프큐엘의 효율성이 왔다갔다한다.

서로 다른 모양의 다양한 요청과 응답이 많다면 그래프큐엘이 효율적이지만 HTTP와 HTTPS에 의한 캐싱을 잘 활용하고 싶거나 요청의 구조가 정해지지 않았을 때는 REST API가 효율적일 가능성이 높다.

하지만 하나의 솔루션만을 선택할 필요없이 백엔드 서버에 두가지 솔루션을 모두 사용할 수 있다. 그러니 우리는 새로운 도구를 얻었고 기존의 도구와 잘 활용한다면 더 나은 서비스를 제공할 수 있을 것이다!!

다크 모드를 설정할 수 없는 웹사이트가 대부분이지만 많은 웹사이트들이 다크모드를 지원하고있다. 다크 모드를 구현하려면 어두운 테마에 맞는 디자인이 추가적으로 들어간다. 추가적인 리소스를 쏟으면서 다크 모드를 구현하는 이유가 무엇일까? 우리가 어두운 곳에서 핸드폰을 할 때 핸드폰 밝기를 낮춘 경험이 있을 것이다. 바로 주변이 어두운 경우 우리의 눈은 빛에 예민해진다. 예민한 눈에 계속해서 밝은 빛을 비추면 눈이 쉽게 피로해지며 눈 건강에도 좋지 않다. 하지만 어두운 곳이 아님에도 빛에 예민한 사용자들이 있다. 이러한 사용자들은 라이트 모드 밖에 없는 웹사이트를 이용할 때 우리가 어두운 곳에서 밝기가 고정된 핸드폰을 하는 느낌을 받게 될 것이다. 그렇기에 웹 접근성을 높이기 위해서 다크 모드를 설정 가능하도록 구현해야한다.

개발 진행

개발 환경

• Next.js
• Typescript
• Emotion

ThemeProvider

이번 프로젝트에서 Emotion을 스타일 라이브러리로 사용하고 있다. 테마 스타일를 적용하기 위해 Emotion에서 제공하는 ThemeProvider 컴포넌트를 커스텀하여 사용했다. ThemeProvider에 Theme을 제공하게 되면 자식 요소에서 해당 Theme을 받아서 사용할 수 있되어 추후 Theme 수정시 일괄적으로 생상 변경이 가능하므로 유지보수에 편리하다.

고려 상황들

window 객체와 Next.js

• 문제 사용자의 다크모드 설정을 localStorage에 저장하고 불러와서 쓰기위해서 window 객체가 필요했다. 하지만 Next.js에서는 window 객체를 React처럼 그냥 사용한다면 ReferenceError: window is not defined 라는 에러를 만나게된다. Next.js는 기본적으로 SSG를 지원하기 때문에 브라우저 환경에서 사용할 수 있는 window 객체 사용 불가능하다.
• 해결 그렇기 때문에 브라우저 환경에서 해당 코드가 실행되게 하기위해 useEffect를 활용해서 마운트 되었을 때 window를 사용해 주었다.

  // 예시 코드
  useEffect(() => {
    if (
      window.localStorage.getItem('welcoming-theme') === 'dark'
    ) {
      setDark(true);
    }
  }, []);

  사용자 테마 감지

  시스템을 다크 테마를 사용하는 사용자에게는 웹사에트 첫 방문시 다크 모드를 적용해서 보여준다면 더 나은 사용자 경험을 제공할 것이다. 사용자의 시스템의 테마를 확인하기위해 prefers-color-scheme을 이용해 확인할 수 있다.

Type error

Typescript와 ThemeProvider를 같이 사용할 때 테마의 타입을 제공하지 않으면 css props에서 theme의 값을 사용할 수 없다. 공식문서를 확인해보면 props.theme을 의도적으로 비워뒀기 때문이다. type-safe를 위해서 비워뒀고 우리가 해당 타입을 정의해서 사용해야한다.

// 예시 코드
import '@emotion/react'

declare module '@emotion/react' {
  export interface Theme {
    color: {
      primary: string
      positive: string
      negative: string
    }
  }
}

Code

_app.tsx 파일 설정

// _app.tsx
import type { AppProps } from 'next/app';
import client from '../apollo';
import { CustomThemeProvider } from '../styles/CustomThemeProvider';

function MyApp({ Component, pageProps }: AppProps) {
  return (
    <CustomThemeProvider>
      <Component {...pageProps} />
    </CustomThemeProvider>
  );
}

export default MyApp;

CustomThemeProvider.tsx 구현

//CustomThemeProvider.tsx
import { Global, ThemeProvider } from '@emotion/react';
import styled from '@emotion/styled';
import { useCallback, useEffect, useState } from 'react';
import { GlobalStyles } from './globals';
import { mode } from './theme';

export const CustomThemeProvider: React.FC = ({ children }) => {
  const [mounted, setMounted] = useState(false);
  const [theme, setTheme] = useState(mode.light);
  const [dark, setDark] = useState(false);
  useEffect(() => {
    setMounted(true);
    if (
      window.localStorage.getItem('welcoming-theme') === 'dark' ||
      (window.matchMedia('(prefers-color-scheme: dark)').matches &&
        !window.localStorage.getItem('welcoming-theme'))
    ) {
      setDark(true);
    }
  }, []);
  useEffect(() => {
    window.localStorage.setItem(
      'welcoming-theme',
      `${dark ? 'dark' : 'light'}`,
    );
    if (window.localStorage.getItem('welcoming-theme') === 'dark') {
      setTheme(mode.dark);
    } else if (window.localStorage.getItem('welcoming-theme') === 'light') {
      setTheme(mode.light);
    }
  }, [dark]);
  const toggleTheme = useCallback(() => {
    setDark((curr) => !curr);
  }, [dark]);

  const body = (
    <ThemeProvider theme={theme}>
      <Global styles={GlobalStyles(theme)} />
      {children}
      <DarkModeBtn type="button" onClick={toggleTheme}>
        {dark ? '라이트 모드로 보기' : '다크 모드로 보기'}
      </DarkModeBtn>
    </ThemeProvider>
  );

  if (!mounted) {
    return <div style={{ visibility: 'hidden' }}>{body}</div>;
  }
  return body;
};

const DarkModeBtn = styled.button`
  position: fixed;
  bottom: 30px;
  right: 30px;
  height: 40px;
  padding: 0 25px;
  border-radius: 20px;
  background: ${({ theme }) => theme.bg.darkBtn};
  color: ${({ theme }) => theme.text.darkBtn};
  font-weight: 600;
`;

theme.ts 테마 파일 설정

// theme.ts
import { Theme, ThemeMode } from '@emotion/react';

declare module '@emotion/react' {
  export interface ThemeMode {
    bg: {
      primary: string;
      bodyBg: string;
      darkBtn: string;
    };
    text: {
      primary: string;
      bodyText: string;
      darkBtn: string;
    };
  }
  export interface Theme extends ThemeMode {
    mediaQuery: {
      mobile: string;
      tablet: string;
      laptop: string;
      desktop: string;
    };
  }
}
interface ThemeGroup {
  light: Theme;
  dark: Theme;
}

const light: ThemeMode = {
  bg: {
    primary: '#35c5f0',
    bodyBg: '#ffffff',
    darkBtn: '#eeeeee',
  },
  text: {
    primary: '#35c5f0',
    bodyText: '#000000',
    darkBtn: '#000000',
  },
};
const dark: ThemeMode = {
  bg: {
    primary: '#050505',
    bodyBg: '#1e1f21',
    darkBtn: '#757575',
  },
  text: {
    primary: '#fbfbfc',
    bodyText: '#d9d9d9',
    darkBtn: '#ffffff',
  },
};
interface MEDIA {
  mobile: string;
  tablet: string;
  laptop: string;
  desktop: string;
}

export const mediaQuery: MEDIA = {
  mobile: '375px',
  tablet: '768px',
  laptop: '1024px',
  desktop: '1600px',
};

export const mode: ThemeGroup = {
  light: { ...light, mediaQuery },
  dark: { ...dark, mediaQuery },
};

Global style 설정

import { css, Theme } from '@emotion/react';

export const GlobalStyles = (theme: Theme) => css`
  /* reset css 적용 */
  body {
    background: ${theme.bg.bodyBg};
    color: ${theme.text.bodyText};
  }
`;

export default GlobalStyles;

위의 코드처럼 css props를 구조분해 할당을 이용하여 theme 값을 받아와서 사용할 수 있다.

• 쇼핑몰의 주요 기능을 구현해보는 프로젝트입니다.
• Github 주소

기술 스택

프레임워크

Next.js

쇼핑몰 컨셉상 검색을 통한 유입 유저가 많다는 것을 생각하여 SSG 또는 SSR을 통해 SEO가 가능한 React 기반 프레임워크인 Next.js를 선정하였다. 추가적으로 Next.js는 자체적인 라우팅 시스템이 있어 기본 React로 구현하는 것보다 아키텍처가 제한된다. 이런 점은 새롭게 배워야한다는 불편함이 있지만 길게 봤을 때는 내가 Next.js를 사용했다는 점 하나만으로 타인이 내 프로젝트의 아키텍처를 볼 때 비교적으로 예상 가능하게 만들어준다는 장점이 있다. 타인 뿐만 아니라 3~4개월 후의 내가 보고 다시 유지보수하기에도 쉬워진다.

언어

Typescript

단순하게 보면 Javascript에 정적타입이라는 컨셉을 추가한 언어다. 하지만 정적타입이라는 컨셉이 추가되면서 개발자한테 정말로 많은 생상성 향상을 제공한다. 명시적인 정적타입을 지원하면서 코드의 가독성을 높이고 TS에서 JS로의 컴파일 단계에서 오류를 포착할 수 있게 되었다.

스타일 라이브러리

Emotion

Emotion은 CSS in JS 컨셉의 style 라이브러리다. 우선 CSS in JS는 기존의 CSS 파일처럼 스타일시트를 문서 레벨로 관리하는 것이 아닌 컴포넌트 레벨로 추상화하여 관리를 하는 개념이다. 이 개념의 style 라이브러리를 React 프로젝트에서 사용할 때 가장 큰 장점은 React의 컴포넌트와 그에 맞는 style 코드를 같은 파일에서 관리가 가능하여 이후 코드 가독성과 유지보수가 편해진다. 그리고 개발이 어려워지는 이유 중에 하나는 수 많은 이름을 지어줘야한다는 점이다. 기존의 CSS를 사용하게 되면 스타일이 필요한 대부분의 요소에 클래스명을 중복되지 않게 지어줘야하며 가독성을 위해 명시적으로 지어줘야한다. 하지만 CSS in JS 개념의 라이브러리를 사용한다면 컴포넌트 내에서만 중복을 피하면 되기 때문에 클래스명 생성에서 오는 개발의 난이도가 낮아진다. CSS in JS에 많이 사용하는 것으로는 Styled-component와 Emotion이 있다. 이중에 Emotion을 고른 이유는 styled component보다 번들 사이즈가 작고, 퍼포먼스가 좋다라는 이유로 Emotion을 사용하기로 했다.

상태관리

Apollo Client

Apollo를 이용하여 간단하게 상태관리 설정이 가능하다. 최근 리덕스 툴킷을 사용하려고 기본 설정을 한 적이 있었는데 리덕스 툴킷이 기존의 리덕스의 기본 설정이 너무 코드가 길고 러닝커브가 크다는 이유에서 등장했고 그에 맞게 러닝커브도 줄고 보일러 플레이트의 크기도 줄었다. 하지만 Apollo와 비교하니 리덕스는 아직도 너무 큰 러닝커브와 보일러 플레이트가 필요했다.

// 아폴로 세팅 예시
import { ApolloClient, InMemoryCache } from '@apollo/client';

const client = new ApolloClient({
  uri: 'http://localhost:5050/graphql',
  cache: new InMemoryCache(),
});

export default client;

데이터 패칭

Apollo & GraphQL

장점 몇가지를 소개하자면 우선 PlayGround라는 GUI 인터페이스를 기본으로 제공한다. 제공하는 DOCS를 통해 쿼리들와 뮤테이션들의 정보를 확인할 수 있고 SCHEMA를 통해 테이블들의 타입 확인이 가능하다.

그리고 GraphQL을 사용하여 필요한 데이터를 위한 쿼리문을 프론트엔드에서 작성해서 사용하므로 언더패칭, 오버패칭을 방지할 수 있다. 다음과 같이 원하는 데이터를 골라서 사용할 수 있다.

// GraphQL 사용 예시
const LOGIN_MUTATION = gql`
  mutation loginMutation($loginInput: LoginInput!) {
    login(input: $loginInput) {
      ok
      token
      error
    }
  }
`;

gql 사용하여 쿼리문을 프론트엔드에서 작성하므로 프론트엔드 개발자가 데이터를 직접 다룰 수 있게 되어 자유도가 올라간다.

코드 스타일

Prettier & ESLint

코드 스타일을 맞추지 않고 개발을 진행하다보면 에러가 생길 확률이 프로젝트가 진행하면 할 수록 커질 수 밖에 없어진다. 이 점을 방지하기 위해 코드 스타일을 컨벤션으로 정하고 프로젝트를 진행하게되는데 문서화된 컨벤션만으로는 강제성을 띄우기 힘들어진다. 강제성을 높이기 위해 ESLint와 Prettier를 이용하였다. Prettier는 문법 오류는 아니지만 미관상의 이유로 가독성이 낮아지는 것을 방지하기 위해 코드를 자동 정렬하고 다듬어준다. ESLint는 문법적으로 오류가 생길 수 있는 부분들에 대해서 에러나 워닝을 띄우고 일부의 에러는 강제변환을 도와준다. ESLint의 코드 스타일은 airbnb 스타일 가이드를 기본으로 채택하여 사용하고 필요하지 않은 룰을 삭제해서 사용하고 있다.

husky & lint-staged

코드 스타일 컨벤션을 강제하기 위해 ESLint를 사용한다면 Husky와 Lint-staged는 Git을 통한 코드 공유를 할 때 ESLint 규정에 어긋나지 않은 코드만 배포할 수 있도록 강제성을 부여한다. husky와 lint-staged를 이용하여 git commit이 명령어가 실행되기 직전에 Staged된 파일들에 우리가 원하는 검사를 하게된다. 여기서 우리가 원하는 검사란 ESLint 체크다. 만약 ESLint 체크를 했을 때 에러를 띄우면 git commit이 실행되지 않고 멈추게 되고 통과를 해야지 git commit 명령어가 끝까지 완료하게 된다.

폴더 구조

.
├── node_modules
├── public
└── src
     ├── __generated__   // apollo codegen을 통해 생성된 graphQL 타입 파일들이 저장된 폴더
     ├── apollo          // apollo 설정 폴더
     ├── components      // 요소들을 정리한 폴더
     ├── constants       // 상수가 저장된 폴더
     ├── hooks           // 커스텀된 hook들이 저장된 폴더
     ├── pages           // page들이 저장된 폴더
     └── styles          // 스타일 관련 코드들이 저장된 폴더

프로젝트 사이트 둘러보기 깃헙 보러가기

다시 한번 Next

이번에 실습 위주의 스터디를 열심히 참여를 해봤다. 주요 기술 스택은 Next.js와 Typescript, useSWR, styled-component였다. 이전에 Next js를 사용해 본적이 있지만 왜 사용해야 하는지를 생각하지 않고 사용을 했고 경험이 많이 부족했었기에 Next의 이점을 제대로 파악하지 못했다. 하지만 이번 기회에 조은님의 기깔나는 설명을 들으면서 Next와 좀 더 친해지는 기회가 됬었다.

Futurama API

첫 주차에 sample apis 사이트의 wines api를 사용하여 조은님이 강의를 진행하고 비슷한 beers api를 이용하여 복습 및 과제를 진행하였고 첫 주차 마무리 과제로 Futurama API를 이용하여 개별 사이트를 만들어 보는 과제를 진행했다. 이전의 wines와 beers API와는 다르게 futurama api는 모든 엔드포인트가 다른 구조의 데이터를 뱉어서 페이지를 구성하는 재미가 있었다. 그 중 신경쓴 엔드포인트를 소개해보도록 하겠다.

Character

character 엔드포인트 같은 경우에는 15가지의 캐릭터들과 해당 캐릭터들의 정보가 담겨 있었다. 문제는 명대사 데이터가 많은 캐릭터들이 있어 한 페이지에 보여주기에는 데이터가 너무 많았다. 다행히도 각 캐릭터들의 id값을 character endpoint 뒤에 넣어서 개별 캐릭터의 데이터만 받아올 수 있어 전체 캐릭터들의 페이지와 동적 라우팅을 이용한 캐릭터 디테일 페이지로 나눠서 구현해볼 수 있었다.

Episodes

퓨처라마의 에피소드가 128개나 되었다. 이 데이터도 너무 많기 때문에 이 데이터를 한페이지에 넣는다면 UX가 너무 좋지 않을 것이라는 것은 당연했다. 하지만 이 데이터는 128개의 에피소드를 원하는 수만큼 가져올 수 없었기 때문에 한번에 받아온 데이터를 페이지네이션을 통해 나눠서 페이지에 보여주는 방법으로 진행하였다. 실제 프로젝트에서는 이런식으로 데이터 처리를 하지 않겠지만 그래도 나름대로 임기응변으로 UX를 끌어올린것 같아 매우 뿌듯했던 페이지였다.

Questions

이 데이터를 보자마자 실제로 문제를 풀어볼 수 있게 진행하면 너무 재밌겠다!!라는 생각이 들었다. 과제에 재미가 빠지면 섭하지 않나? 그래서 원하는 대로 구현을 했다. 문제 수는 28개의 문제였기에 7문제씩 4페이지로 나눴다. 누군가는 굳이?라고 생각할 수 있지만 최근에 친구의 부탁으로 32문항의 설문을 진행한적이 있는데 몇번을 그만두고 싶었는지 모른다. 문제는 32문항이라는 문항 수보다는 한페이지에 있다보니 그림하나 없는 논문을 읽는 느낌마저 들었다. 그래서 굳이 4페이지로 나눠서 페이지를 구현해보았다. 하지만 개별 문제들과 페이지네이션과 결과 페이지를 따로 컴포넌트로 나눴기때문에 따로 상태관리 라이브러리 없이 구현하는데 너무 힘들었다. 이전에 프로젝트를 할 때 당연하게 상태관리 라이브러리를 사용했었는데 이번 기회를 통해 필요성을 확실히 느끼는 프로젝트가 되었다.

마무리

이번 프로젝트를 통해 오랜만에 리액트기반 환경에서 개발을 해보았다. 한동안 바닐라 자바스크립트를 통해서 개발을 진행했는데 비교적으로 코드를 깔끔하게 짜기가 좋았고 아케텍처가 제한적이기 때문에 몇개월이 흘러서 봐도 코드를 이해하기 쉽겠다는 생각이 들었다. 그리고 기본 리액트보다 라우팅을 기본적으로 제공하기 때문에 한번 익숙해지면 새로운 프로젝트를 시작하는 허들이 낮아졌다고 생각한다. 거기다 SSG를 이용한 SEO에 강점도 갖고 있기때문에 현재 프론트엔드 개발을하는데 필수로 알아둬야하는 스택 중에 하나라고 생각된다.

프론트엔드스쿨 동료와 네이버 채용 사이트를 클론 코딩을 하던 도중 처음 보는 상황을 맞닦드렸고 국내에 이에대한 글이 없는 듯하여 정리하고 넘어가려고 한다. 네이버 채용 사이트처럼 상단 내비게이션 바와 슬라이드를 겹치게 놓고싶었다.

하지만 슬라이드를 상단 내비게이션 바의 영역을 침범하기위해 position: absolute를 주었더니 위치는 올라갔지만 내비게이션 바를 덮어버리면서 네비게이션바가 나오지 않게 되었다. 그래서 네비게이션 바 밑으로 보내기위해서 슬라이드에 z-index: -1;을 주니까 원하는데로 내비게이션바 아래로 내려갔지만 슬라이드 내부의 a태그가 눌리지 않게 되는 상황을 마주하게되었다.

내비게이션바에도 position을 설정하고 슬라이드와 내비게이션 바에 z-index를 주면서 원하는대로 구현을 했지만 z-index에 음수값을 주었을 때 a태그가 왜 작동을 하지 않는지에 대해서 의문이 생겨 찾아보게 되었다.

추론

MDN 문서를 읽으면 flex 혹은 grid 컨테이너 요소의 자식 요소 중에 z-index가 auto가 아닐 경우 쌓임 맥락(stack context)가 생성된다고 한다. 쌓임 맥락 안의 자식 요소는 해당 규칙에 의해서 쌓이게 된다고 정의되어 있다. 하지만 부모요소의 아래로 쌓이게 되는 점에 대해서는 설명이 없다. 그래서 직접 실험해보고 알게된 점을 바탕으로 정리해보겠다.

HTML 구성

<!-- html -->
<div class="outer">
  <div class="inner">
    <a href="javascript:alert('동작');" class="a1">a01</a
    ><a href="javascript:alert('동작');" class="a2">a02</a>
  </div>
</div>

상황 1

/* css */
.a1 {
  z-index: -1;
}
.a2 {
  z-index: 1;
}

위처럼 .a1에 z-index: -1;만 준다면 .a2와 눈으로 볼 수 있는 차이는 없다

a태그도 잘 클릭이 되며 alert도 잘 작동한다.

상황 2

/* css */
.inner {
  display: flex; 
  /* 또는 display: grid; */
}
.a1 {
  z-index: -1;
}
.a2 {
  z-index: 1;
}

하지만 부모 요소에 display: flex; 혹은 grid를 준다면 a태그가 눌리지 않으며 커서가 pointer로 변하지 않는다. 처음 이 상황을 봤을 때는 어리둥절했었다. 시각적으로는 상황1과 다를게 없기 때문이다. 하지만 부모 요소에 배경색을 넣으면 차이가 보인다. .a1요소가 부모 밑에 깔려있기 때문에 부모에 가로막혀서 클릭이 되지않았던 것이다.

상황 3

/* css */
.outer {
  background-color: aqua;
}
.inner {
  display: flex; 
  /* 또는 display: grid; */
}
.a1 {
  z-index: -1;
}
.a2 {
  z-index: 1;
}

그렇다면 a는 부모요소의 밑으로만 간것인지 아니면 특정 층에 끼어있는 것인지 확인해보기 위해서 .inner의 배경색 pink을 없애고 .outer에 배경색 aqua를 주었다. .outer 요소의 display는 flex가 아닌데도 더 아래에 깔리게 되었다.

상황 4

이번엔 부모 요소가 아닌 조상 요소에 display: flex;가 있을 때도 z-index: -1;인 요소가 아래로 깔리는지 확인해보겠다;

/* css */
.outer {
  display: flex; 
  /* 또는 display: grid; */
}
.inner {
  background-color: pink;
}
.a1 {
  z-index: -1;
}
.a2 {
  z-index: 1;
}

잘 보이며 잘 동작한다. 부모 요소가 아닌 조상 요소의 display에는 영향을 받지않는 것으로 보인다.

상황 5

이번엔 div의 배경색은 없애고 body에 배경색을 bisque로 줘서 어디까지 내려가는지 확인해보겠다.

/* css */
body {
  background-color: bisque;
}
.inner {
  display: flex; 
  /* 또는 display: grid; */
}
.a1 {
  z-index: -1;
}
.a2 {
  z-index: 1;
}

이미지를 보면 body 위에 있는 것처럼 보인다.

상황 6

더 정확한 확인을 위하여 감싸던 div요소를 없애고 body에 flex를 줘서 확인해보겠다.

<!-- html -->
<body>
  <a href="javascript:alert('동작');" class="a1">a01</a
  ><a href="javascript:alert('동작');" class="a2">a02</a>
</body>

/* css */
body {
  display: flex; 
  /* 또는 display: grid; */
  background-color: bisque;
}
.a1 {
  z-index: -1;
}
.a2 {
  z-index: 1;
}

신기하게도 눈으로 보기엔 body 위에 있다고 보이지만 클릭이 되지않고 cursor가 pointer로 변하지 않는걸로 보아 body 아래에 있는 것처럼 느껴진다.

결론

display: flex 또는 grid인 컨테이너의 자식 요소에 z-index: -1;를 주면 body 아래까지 내려가지만 시각적으로는 body위에 있는 것처럼 보인다.

마무리

💡직접 읽어보면 뼈가 되고 살이 되는 출처 👉쌓임 맥락 MDN 문서

우리는 변수를 선할 때 var, let, const 키워드를 사용한다. ES6에서 let, const가 도입되기 전에는 var가 오랬동안 유일하게 변수 선을 위해 사용되어 왔다. 하지만 ES6이후에 대부분의 코드에서 var를 사용하지 않고 있다. 오늘은 왜 var를 꺼려하는지에 대해서 알아보겠다.

var의 특징

1. 호이스팅 후 초기화

자바스크립트에서 호이스팅은 꽤나 중요한 개념이다. 호이스팅은 단순 번역으로 끌어올린다라는 의미다. 자바스크립트에선 인터프리터가 변수와 함수의 메모리 공간을 선언하기 전에 미리 할당하는 것을 의미한다. 그렇기 때문에 var, let, const 모두 호이스팅이 일어난다. 하지만 var의 경우 호이스팅 후 변수를 undefined로 값이 초기화되기 때문에 선언 전에 참조가 가능해진다.

console.log(a); // ReferenceError: Cannot access 'i' before initialization
let a;

console.log(b); // undefined
var b;

한마디로 변수의 선언 위치가 자유로워지고 이 변수를 내가 undefined로 할당을 한건지 아니면 원하는 값으로의 할당이 아직 이루어지지 않았는지 확인이 힘들다.

2. 중복 선언

let과 const의 경우 선언한 변수를 다시 선언하는 경우 에러를 발생한다. 하지만 var의 경우 변수 이름이 중복되어도 에러가 발생하지 않는다.

let a;
let a; // SyntaxError

var b;
var b; // No problem~!!

이 특성 때문에 원치않게 이미 선언한 변수의 값에 영향을 미치게 되어도 실수를 알아차리기 힘들다.

3. 스코프

let, const의 경우는 블록 레벨 스코프를 갖고, var의 경우 함수 레벨 스코프를 갖게 된다. 이 부분은 예제를 먼저 보겠다.

for (let a = 0; a < 3; a++) {
 ...
}
console.log(a); // ReferenceError

for (var b = 0; a < 3; b++) {
 ...
}
console.log(b); // 3

예제처럼 let의 경우 for문 안의 블록 밖에서는 변수가 참조가 불가능하지만 var의 경우 변수가 함수 레벨 스코프이기에 블록 밖에서도 참조가 가능하다. 위의 예제에서는 동작에 문제가 없지만 setTimeout() 함수와 함께 비동기로 사용한다면 문제가 발생한다.

for (let a = 1; a < 4; a++) {
  setTimeout(() => {
    console.log(a + "번째");
  }, 1000);
} 
// 1 번째
// 2 번째
// 3 번째

for (var b = 1; b < 4; b++) {
  setTimeout(() => {
    console.log(b + "번째");
  }, 1000);
}
// 4 번째
// 4 번째
// 4 번째

for문이 실행되면서 a 또는 b 가 0인 스코프, 1인 스코프, 2인 스코프 ... 들을 생성해줍니다. let을 사용한 경우는 for문의 범위가 적용되기 때문에 이미 for문이 다 실행되었어도 이전의 스코프의 a 값을 참조하지만 var의 경우 함수 레벨 스코프이므로 for문이 실행되면서 생성한 스코프를 빠져나와서 최좀의 b를 참조하게 되어 예상한 결과와 다르게 나온다.

정리

var의 경우 호이스팅 후 undefined로 초기화가 되어 해당 undefined가 내가 할당했는지 자동으로 초기화된 값인지 확인이 어렵고 var로 동일한 변수 이름을 중복하여 선언이 가능하므로 var로 변수 선언 시 이전의 변수 값에 영향을 미치는 건지 모호해진다. 그리고 블록 레벨 스코프가 아닌 함수 레벨 스코프이기 때문에 필요하지 않은 전역변수가 많아질 수 있고, 비동기처리시 원하지 않게 동작할 수 있다.

💡직접 읽어보면 뼈가 되고 살이 되는 출처 👉모던 자바스크립트 DEEP DIVE(도서 이웅모 저) 👉https://developer.mozilla.org/ko/docs/Glossary/Hoisting 👉https://velog.io/@yonyas/Javascript-for문과-setTimeout-동시에-쓸-때-var와-let의-차이

https://www.acmicpc.net/problem/9095

문제 설명

문제

정수 4를 1, 2, 3의 합으로 나타내는 방법은 총 7가지가 있다. 합을 나타낼 때는 수를 1개 이상 사용해야 한다.

• 1+1+1+1
• 1+1+2
• 1+2+1
• 2+1+1
• 2+2
• 1+3
• 3+1

정수 n이 주어졌을 때, n을 1, 2, 3의 합으로 나타내는 방법의 수를 구하는 프로그램을 작성하시오.

입력

첫째 줄에 테스트 케이스의 개수 T가 주어진다. 각 테스트 케이스는 한 줄로 이루어져 있고, 정수 n이 주어진다. n은 양수이며 11보다 작다.

출력

각 테스트 케이스마다, n을 1, 2, 3의 합으로 나타내는 방법의 수를 출력한다.

문제 풀이

이 문제는 답이 나오는 규칙을 먼저 찾아야한다. 규칙을 보기 위해 1, 2, 3, 4의 답들을 구해 보겠다.

1

• 1

따라서 답은 1.

2

• 1 + 1
• 2

답은 2.

3

• 1 + 1 + 1
• 1 + 2
• 2 + 1
• 3

답은 4.

4

• 1 + 1 + 1 + 1
• 1 + 1 + 2
• 1 + 2 + 1
• 2 + 1 + 1
• 1 + 3
• 3 + 1
• 2 + 2

답은 7이다.

4의 답은 3, 2, 1의 답을 합친 것과 같다. 그 이유는 4의 답의 구성은 3의 답 구성에 1을 더한 것, 2의 답 구성에 2를 더한 것, 1의 답 구성에 3을 더한 것들로 구성되어 있기 때문이다.

다시 한번 4의 답 구성을 보자.

• 1 + ( 1 + 1 + 1 )
• 1 + ( 1 + 2 )
• 1 + ( 2 + 1 )
• 1 + ( 3 )
• 2 + ( 1 + 1 )
• 2 + ( 2 )
• 3 + ( 1 )

그렇기 때문에 입력값 중 최대값까지의 답을 구하고서 순서에 맞게 출력값을 붙여주면 된다.

코드

// 제출용 input
let input = require('fs')
  .readFileSync('/dev/stdin')
  .toString()
  .trim()
  .split('\n')
  .splice(1);

// 실행용
// const input = '3\n4\n7\n10'.split('\n').splice(1);
//ansArr[n] : 정수 n을 1, 2, 3의 합으로 나타내는 방법의 수
const ansArr = Array(10);
let result = '';

//초기값 설정
ansArr[0] = 1;
ansArr[1] = 2;
ansArr[2] = 4;

for (let i = 3; i < 10; i++) {
  //n이 10 이하이므로 10까지 방법의 수 저장
  ansArr[i] = ansArr[i - 1] + ansArr[i - 2] + ansArr[i - 3];
}
//입력에 맞는 방법의 수 메모에서 출력
input.forEach((value) => {
  result += `${ansArr[value * 1 - 1]}\n`;
});

console.log(result);

Modal(이하 모달)은 사용자의 이목을 끌기 위해 사용하는 화면전환 기법 중에 하나다. 이번 프로젝트에서는 사용자가 어떤 행동을 하였을 때 이 행동을 정말로 진행할 것인지 확인 하는 용도로 사용을 하기도 하였고, 로그인이 필요한 기능을 수행하려 할 때 로그인 창을 모달로 띄워서 페이지 이동 없이 로그인을 진행하도록 수정하려고한다. 모달은 모달 컴포넌트를 만든 후 필요한 컴포넌트에서 불러오면 된다. 하지만 그냥 불러온다면 모달 컴포넌트가 보이기로는 맨앞에 보이지만 컴포넌트 트리 속 어딘가에 위치하게 되서 직관적이지 않게된다.

그래서 react-dom의 createPortal을 사용해서 기본의 컴포넌트 트리에서 벗어나게 직관적으로 모달을 구현해보려고 한다.

2. 구현 코드

<!--public/index.html-->
<body>
    <noscript>You need to enable JavaScript to run this app.</noscript>
    <div id="root"></div>
    <div id="modal"></div> // <- 코드 추가
  </body>

우선 리액트 프로젝트 파일 내부의 public/index.html파일에 root 밑에 <div id="modal"></div> 컨테이너를 추가한다.

//Modal.jsx
import React from 'react';
import { createPortal } from 'react-dom';
import styled from 'styled-components';

const ModalBg = styled.div`
  display: flex;
  position: fixed;
  top: 0;
  left: 0;
  z-index: 9999;
  align-items: center;
  justify-content: center;
  width: 100vw;
  height: 100vh;
  background-color: #ffffffe2;
`;

const ModalBox = styled.div`
  width: 25rem;
  background-color: white;
`;

const Modal = ({ setModalShow }) => {
  const handleOk = () => {
    console.log('댓글 삭제');
  };
  return createPortal(
    <ModalBg>
      <ModalBox>
        <ModalTitle>댓글 삭제</ModalTitle>
        <ModalContent>댓글을 정말로 삭제하시겠습니까?</ModalContent>
        <ModalBtnBox>
          <ModalBtn cancel onClick={() => setModalShow(false)}>
            취소
          </ModalBtn>
          <ModalBtn onClick={() => handleOk()}>확인</ModalBtn>
        </ModalBtnBox>
      </ModalBox>
    </ModalBg>,
    document.getElementById('modal')
  );
};

export default Modal;

그리고 Modal 컴포넌트의 반환 값을createPortal로 감싸주고 원하는 element를 지정해주면 된다. (위 코드에서 모달생성에 필수적이지 않다고 생각한 css 코드는 삭제했습니다.)

실행해보면 시각적으로는 똑같지만 html element를 보면 모달이 기존의 컴포넌트 트리에서 빠져나온 것을 확인할 수 있다.

3. Modal 배경 스크롤 막기

모달도 잘 만들었는데 뒤에 배경이 스크롤이 된다면 완성도가 많이 떨어져 보일 것이다. 그래서 모달의 글의 마지막은 스크롤을 막는 방법이다.

3-1. 구현 방법

body 태그의 css를 position을 fixed로 변경하고, top을 현재 스크롤 위치로 하고 overflow-y: scroll; width: 100%;을 추가하면 스크롤 방지를 할 수 있다.

해당 css를 변경할 때는 useEffect를 사용할 것이다. 모달이 사라질 때에는 useEffect의 return을 사용해 body의 cssText를 리셋시킨 다음 window.scrollTo를 이용해 현재 스크롤 위치로 이동시키면 된다.

3-2. 구현 코드

  useEffect(() => {
    document.body.style.cssText = `
      position: fixed; 
      top: -${window.scrollY}px;
      overflow-y: scroll;
      width: 100%;`;
    return () => {
      const scrollY = document.body.style.top;
      document.body.style.cssText = '';
      window.scrollTo(0, parseInt(scrollY || '0', 10) * -1);
    };
  }, []);

4. 마무리

프로그래밍을 잘 모르는 사람이 볼 때는 모달을 컴포넌트 트리에서 빼든 안 빼든 css적으로 동일하다면 상관없을 것이다. 하지만 이런 사소한 부분 하나 하나 모여 코드의 완성도와 깔끔함이 결정된다고 믿기에 이 방법이 좋은 프로그래밍이라고 생각한다.

💡직접 읽어보면 뼈가 되고 살이 되는 출처 👉https://codingbroker.tistory.com/126 👉http://yoonbumtae.com/?p=3776

난 책을 좋아하지 않는다. 소설보다는 영화를, 설명서보다는 언박싱 브이로그를 보는 걸 더 좋아한다. 그래서 프로그래밍 공부를 할 때도 책보다는 인터넷 강의를 보면서 공부했다. 하지만 프로젝트들을 하면서 새로운 것을 익히고 써먹을 때마다 혹은 알고리즘 공부를 할 때마다 자바스립트에 대한 공부가 부족하다는 것이 느껴졌다. 그래서 이번에 자바스크립트 기초 공부를 하기 시작했다. 그래서 여러가지 자바스크립트 서적과 강의를 추천받아서 알아보다가 You don't know JS를 알게되었다. 지금 읽고 있는데 생각보다 재밌고 생각보다 유익해서 실제로 프로젝트에 바로 적용할 수 있을 법한 팁들도 많이 존재해서 단순히 읽고 끝내는 것이 아니라 정리가 필요하다가 느꼈다. 바로 시작한다.

2. 1장 타입과 문법📕

1. 1절 타입

내장 타입

자바스크립트에는 7가지 내장 타입이 있다.

• null
• undefined
• boolean
• number
• string
• object
• symbol(ES6부터 추가)

값 타입은 'typeof' 연산자로 알 수 있다. 하지만 null의 경우 object로 반환된다.

typeof null === object // true

값이 없는 vs 선언되지 않은

var a;

a; // undefined
b; // ReferenceError

typeof a; // undefined
typeof b; // undefined

위의 예제에서 보면 b;는 선언되지 않았기 때문에 에러를 던진다. 하지만 typeof b;의 경우에는 에러를 던지지 않고 undefined를 반환한다. 이를 이용하면 유용한 safe guard를 만들 수 있다.

// DEBUG를 선언하지 않은 경우
// 1
if(DEBUG) {
  console.log("디버깅을 시작합니다.");
}
// 2
if(typeof DEBUG !== undefined) {
  console.log("디버깅을 시작합니다.");
}

1번의 경우 에러를 던지지만 2번의 경우 단순히 if문을 넘어서 프로그램이 진행된다.

2. 2절 값✍️

특수 값

null 타입의 값은 null 뿐이다. 마찬가지로 undefined 타입의 값은 undefined뿐이다. 수학 연산시 두 피연산자가 숫자가 아닐 경우 유효한 숫자가 나올 수 없으므로 그 결과는 NaN이다. 하지만 NaN은 그자 대로 글자아님(Not a Number)보다는 유효하지 않은 숫자라는 명칭이 더 올바르다. 왜냐하면 typeof NaN === number이기 때문이다. 또한 NaN의 특이한 점은 이뿐만이 아니라 null과 undefined와는 다르게 NaN !== NaN이다. 자바스크립트에는 두가지의 0(영)이 존재한다. 바로 +0과 -0이다.

값 vs 레퍼런스

자바스크립트는 포인터라는 개념이 없고 참조하는 방법도 다른 언어들과 다르다. 우선 어떤 변수가 다른 변수를 참조하는 것은 불가능하다. 자바스크립트는 값 또는 레퍼런스의 할당 맟 전달을 제어하는 구문 암시가 전혀 없다. 대신, 값의 타입만으로 값 복사인지 레퍼런스 복사인지 결정된다. null, undefined, string, number, boolean과 symbol같은 단순 값은 언제나 값 복사 방식으로 할당/전달된다. 개체나 함수 등 합성 값은 레퍼런스 복사로 할당/전달된다.

var a = 2;
var b = a;
b++;
a; // 2
b; // 3

var c = [1, 2, 3];
var d = c;
d.push(4);
c; // [1, 2, 3, 4];
d; // [1, 2, 3, 4];

💡직접 읽어보면 뼈가 되고 살이 되는 출처 👉YOU DON'T KNOW JS(카일 심슨 지음)

&nbsp이전에 우리는 Webpack을 사용해서 CRA를 사용하지 않고 리액트 프로젝트를 만들었다. &nbsp이번에는 해당 프로젝트에 Typescript를 사용할 수 있게 설정을 진행할 것이다. &nbsp이번에도 마찬가지로 원본 블로그의 흐름을 그대로 따라간다. 하지만 나는 tslint가 아닌 eslint를 사용할 것이여서 약간의 차이가 존재한다. 출처를 보시려면 여기를 클릭해주세요.

이전 글을 아직 보지 않았다면 Webpack으로 React 프로젝트 만들어보기(❌CRA)를 먼저 보고와주세요!

2. 타입스크립트 적용하기

2-1. 패키지 설치

npm i -D typescript @babel/preset-typescript ts-loader fork-ts-checker-webpack-plugin

• typescript: Typescript(타입스크립트) 필수 라이브러리
• @babel/preset-typescript: babel(바벨)에서 Typescript(타입스크립트)를 빌드하기 위해 필료한 라이브러리
• ts-loader: Webpack(웹팩)에서 Typescript(타입스크립트)를 컴파일 하기 위해 필요한 라이브러리
• fork-ts-checker-webpack-plugin: ts-loader의 성능을 향상시키기 위한 라이브러리

2-2. Webpack 설정하기

webpack.config.js를 열고 아래와 같이 설정합니다.

const path = require('path');

const HtmlWebpackPlugin = require('html-webpack-plugin');

// Typescript(타입스크립트)를 빌드할 때 성능을 향상시키기 위한 플러그인를 불러오기
const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin'); 

module.exports = {
  entry: {
    // 번들 파일(bundle)의 시작 파일(Entry)을 jsx에서 tsx로 변경
    'js/app': ['./src/App.tsx'],
  },
  output: {
    path: path.resolve(__dirname, 'dist/'),
    publicPath: '/',
  },
  module: {
    rules: [
      // Webpack(웹팩)에서 Typescript(타입스크립트)를 사용하기 위해 js|jsx를 ts|tsx로 수정 후 ts-loader를 추가
      // ts-loader의 옵션은 성능 향상을 위해서
      {
        test: /\.(ts|tsx)$/,
        use: [
          'babel-loader',
          {
            loader: 'ts-loader',
            options: {
              transpileOnly: true,
            },
          },
        ],
        exclude: /node_modules/,
      },
    ],
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: './src/index.html',
      filename: 'index.html',
    }),
    // Typescript(타입스크립트)의 컴파일 속도 향상을 위한 플러그인을 설정
    new ForkTsCheckerWebpackPlugin(),
  ],
};

2-3. tsconfig.json 파일 설정하기

&nbsp루트 디렉토리에tsconfig.json을 만들고 아래와 같이 수정합니다.

{
  "compilerOptions": {
    "target": "es6",
    "module": "esnext",
    "moduleResolution": "node",
    "noResolve": false,
    "noImplicitAny": false,
    "removeComments": false,
    "sourceMap": true,
    "allowJs": true,
    "jsx": "react",
    "allowSyntheticDefaultImports": true,
    "keyofStringsOnly": true
  },
  "typeRoots": ["node_modules/@types", "src/@type"],
  "exclude": [
    "node_modules",
    "build",
    "scripts",
    "acceptance-tests",
    "webpack",
    "jest",
    "src/setupTests.ts",
    "./node_modules/**/*"
  ],
  "include": ["./src/**/*", "@type"]
}

2-4. babel 설정하기

&nbsp 루트 디렉토리의 .babelrc를 아래와 같이 수정합니다.

{
  "presets": [
    [
      "@babel/preset-env",
      { "targets": { "browsers": ["last 2 versions", ">= 5% in KR"] } }
    ],
    "@babel/react",
    "@babel/typescript" // Typescript(타입스크립트)가 컴파일 가능하도록 추가
  ]
}

2-5. Typescript 스타일 코딩

&nbspReact에서 Typescript를 사용하기 위해 ./src/App.jsx를 ./src/App.tsx로 이름을 변경하고 아래와 같이 수정합니다.

import * as React from 'react';
import * as ReactDOM from 'react-dom';

interface Props {}

const App = ({  }: Props) => {
  return <h1>Hello World!</h1>;
};

ReactDOM.render(<App />, document.getElementById('app'));

2-6. 실행해보기

npm start

&nbsp위의 명령어를 실행하고 인터넷 브라우저에서 http://localhost:8080/로 들어가면 Hello World!가 보이면 정상적으로 잘 작동하는 것이다.

npm run build

&nbsp그리고 빌드를 했을 때 dist 폴더가 생성되는 지 확인해주면 됩니다.

3. 마치며

&nbsp이전 프로젝트에 바로 진행을 해서 비교적 간단하게 적용을 할 수 있었다. 하지만 찾아보면 더 많은 설정 옵션들이 있으니 다른 옵션들도 적용해봐야할 것 같다. 굿바이~~

💡직접 읽어보면 뼈가 되고 살이 되는 출처 👉https://dev-yakuza.posstree.com/ko/react/typescript/

&nbsp물론 CRA를 이용하면 간편하게 리액트 프로젝트를 만들 수 있다. 프로젝트 만드는 시간도 절약되고 다른 거를 찾아 볼 필요도 없다. &nbsp하지만 CRA는 뭐랄까 종합선물세트같은 느낌이다. 너가 뭘 필요할지 몰라서 기본적인 거 다 준비해봤어. 같은 느낌이랄까? 그래서 나는 내가 필요한 기능만 적절하게 첨가해서 프로젝트를 생성하기 위해 Webpack을 배우기로 했다!🕺

2. Webpack으로 프로젝트 생성하기💻

&nbsp우선 한가지 밝히자면 이번 글은 한 곳에서 너무나도 잘 설명이 되어 있기 때문에 많은 부분이 비슷하다. 하지만 내가 다시 한번 정리하는 차원 + 따라하다 나온 이슈 하나 해결 이 두가지 이유로 글을 적고있다. 원본은 이후 출처에 게시하겠지만 지금 바로 원본이 보고 싶으시다면 여기로 가시면 됩니다.

2-1. 프로젝트 폴더 생성🗂

mkdir react_project cd react_project npm init -y

2-2. 필요한 패키지 설치📚

npm i react react-dom npm i -D webpack webpack-cli html-webpack-plugin webpack-dev-server babel-loader @babel/core @babel/preset-env @babel/preset-react rimraf

패키지 설명

• react, react-dom: React 개발에 필요한 필수 패키지
• webpack: Webpack(웹팩) 라이브러리
• webpack-cli: Webpack(웹팩)을 명령어로 조작하기 위한 라이브러리
• html-webpack-plugin: Webpack(웹팩)에서 HTML을 다루기 위한 플러그인
• webpack-dev-server: Webpack(웹팩)으로 로컬에서 개발하기 위한 테스트 서버
• babel-loader: Webpack(웹팩)에서 babel(바벨)을 다루기 위한 라이브러리
• @babel/core: babel(바벨)로 컴파일하기 위한 라이브러리
• @babel/preset-env: babel(바벨)로 컴파일시 어떤 타겟으로 지정할지 설정하는 라이브러리
• @babel/preset-react: React(리액트)를 babel(바벨)로 컴파일하기 위한 라이브러리
• rimraf: Mac과 윈도우즈에서 동일한 명령어로 폴더를 삭제하기 위한 라이브러리

2-3. package.json 설정📏

&nbsppackage.json 파일에 Webpack을 동작시키기 위한 script를 추가합니다.

{
  "name": "react_project",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "webpack serve --mode development",
    "prebuild": "rimraf dist",
    "build": "webpack --progress --mode production"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "react": "^17.0.2",
    "react-dom": "^17.0.2"
  },
  "devDependencies": {
    "@babel/core": "^7.14.6",
    "@babel/preset-env": "^7.14.5",
    "@babel/preset-react": "^7.14.5",
    "babel-loader": "^8.2.2",
    "html-webpack-plugin": "^5.3.1",
    "rimraf": "^3.0.2",
    "webpack": "^5.39.1",
    "webpack-cli": "^4.7.2",
    "webpack-dev-server": "^3.11.2"
  }
}

script 명령어 설명

• "start": "webpack server --mode development": npm start 또는 npm run start로 실행되는 스크립트입니다. Webpack(웹팩)의 개발 서버를 development 모드로 실행시킵니다. Webpack(웹팩)을 실행시킬 때는 항상 모드(development 또는 production)를 설정해야합니다.
• "prebuild": "rimraf dist": npm run build로 build 스크립트를 실행하면 build 스크립트전에 이 스크립트가 실행됩니다. pre와 post로 스크립트 실행전, 실행후 실행시키고 싶은 스크립트를 실행시킬 수 있습니다. 저는 빌드후 생성되는 폴더를 지우고 다시 만들기 위해 사용하고 있습니다.
• "build": "webpack --progress --mode production": npm run build로 실행되는 스크립트입니다. Webpack(웹팩)을 production 모드로 실행시켜 번들링(bundling)합니다. –progress은 빌드 진행 과정을 모니터링하기 위한 옵션입니다.

2-4. Webpack 설정하기

&nbsp루트 폴더에 webpack.config.js 파일을 생성하고 다음과 같이 설정합니다.

const path = require('path'); //절대경로를 참조하기 위해 path를 불러오기

const HtmlWebpackPlugin = require('html-webpack-plugin'); //웹팩에서 HTML을 다루기위한 플로그인을 불러오기

module.exports = {
  // 번들 파일로 만들기 위한 시작 파일(entry)을 설정
  //생성될 번들 파일은 js 폴더 하위에 app.js라는 이름으로 생성
  //이 파일은 ./src/App.jsx를 시작으로 번들링(하나로 합치기)합니다.
  entry: {
    'js/app': ['./src/App.jsx'],
  },

  //생성된 번들 파일(bundle)은 ./dist/ 폴더에 생성
  //publicPath를 지정함으로써 HTML등 다른 파일에서 생성된 번들을 참조할 때, /을 기준으로 참조
  output: {
    path: path.resolve(__dirname, 'dist/'),
    publicPath: '/',
  },

  //React(리액트) 파일인 jsx와 js는 babel(바벨)을 이용하여 빌드
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        use: ['babel-loader'],
        exclude: /node_modules/,
      },
    ],
  },

  //./src/index.html 파일을 dist 경로에 index.html로 파일을 생성
  //파일을 생성할 때, Webpack(웹팩)이 만든 번들 파일(/js/app.js)를 HTML에 추가하여 생성
  plugins: [
    new HtmlWebpackPlugin({
      template: './src/index.html',
      filename: 'index.html',
    }),
  ],
};

2-5. babel 설정하기⚙️

&nbsp루트 디렉토리에 .babelrc를 생성하고 아래와 같이 설정합니다.

{
  "presets": [
    [
      "@babel/preset-env",
      { "targets": { "browsers": ["last 2 versions", ">= 5% in KR"] } }
    ],
    "@babel/react"
  ]
}

&nbspbabel(바벨)로 컴파일 할 때, targets을 지정해줬어요. 브라우저의 상위 버전 두개(예: IE 11, 10)와 한국(KR)에서 5% 이상의 점유율을 가지고 있는 브라우저에 대응하여 컴파일되도록 설정했어요. 그리고 "@babel/react"을 통해 React(리액트)도 컴파일될 수 있도록 설정했어요.

2-6. HTML 만들기

React(리액트)를 사용할 HTML 파일을 ./src/index.html에 생성하고 다음처럼 수정합니다.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Hello World</title>
  </head>
  <body>
    <div id="app"></div>
  </body>
</html>

2-7.React 파일 만들기📒

&nbsp ./src/App.jsx를 생성하고 아래와 같이 수정합니다.

import React from 'react';
import ReactDOM from 'react-dom';

const App = () => {
  return <h1>Hello World!</h1>;
};
ReactDOM.render(<App />, document.getElementById('app'));

2-8. 실행해보기🖥

npm start

&nbsp터미널에서 위의 명령어를 실행하면 터미널에서 다음과 같은 화면이 보일 것이다.

그리고 인터넷 브라우저에서 http://localhost:8080/로 들어가면 Hello World!가 보이면 정상적으로 프로젝트를 시작한 것이다.

&nbspnpm start가 잘 작동한다면 build도 해보자.

npm run build

&nbsp실행되면 ./dist/ 폴더와 하위에 index.html과 /js/app.js가 생성된 것을 확인할 수 있다. 또한 index.html을 열어보면 우리가 만든 index.html과는 다르게 <script type="text/javascript" src="/js/app.js"></script>이 추가된 것을 확인할 수 있다.

3. 마치며🥳

&nbsp이제 웹팩으로 리액트 프로젝트를 만들 수 있다 정도인 것 같다. 웹팩을 더 공부해서 앞으로는 내가 원하는 프로젝트를 가볍게 시작할 수 있다면 좋을 것 같다.👍

💡직접 읽어보면 뼈가 되고 살이 되는 출처 👉https://dev-yakuza.posstree.com/ko/react/start/ 👉https://stackoverflow.com/questions/59611597/error-cannot-find-module-webpack-cli-bin-config-yargs

&nbsp우리는 ESLint를 프로젝트에 적용시킬 때는 협업하는 모든 사람들이 같은 규칙 내에서 코딩을 하는 것을 예상한다. 하지만 가끔은 규칙을 지키지 않고 깃헙에 코드를 푸시할 때가 생긴다. 내 경우에도 가끔 오랜 코딩에 지쳐서 깜빡하고 ESLint 확인을 안하고 푸시할 때가 있었다. 뿐만 아니라 내가 직접 본 적은 없지만 어떤 팀에서는 전혀 규칙을 지키지 않고 코딩을 하는 사람도 있다고 한다.(그럼 왜 굳이 ESLint를 적용시켰을까...🥲)

&nbsp그래서 우리는 git commit 또는 git push와 같은 git 이벤트가 일어나기 전에 우리가 원하는 스크립트를 실행하기 위해서 git 이벤트 사이에 갈고리(hook)를 걸어주는 것이다. 이것을 git hook 제어라고 한다. 우리는 이런 git hook 제어를 위해서 husky 라이브러리를 사용할 것이다.

&nbsp그러면 lint-staged는 뭐냐? 우선 stage 상태를 이해해야한다. 파일들이 git add로 커밋 대상이 된 상태를 stage 상태라고 한다. stage 상태의 git 파일에 대해 lint와 우리가 설정해둔 명령어를 실행해주는 라이브러리다.

2. husky & lint-staged 사용하기

2-1.husky & lint-staged 설치하기💻

&nbsp이제 실질적인 코드들을 살펴보자. 우선 husky & lint-staged를 설치하자.

npx mrm lint-staged

&nbsp여기서 mrm이란 오픈소스 프로젝트의 환경 설정을 동기화 하기 위한 도구이다. mrm을 이용하면 lint-staged와 husky를 간편하게 설정해줄 수 있다.👍

&nbsp위 명령어를 실행하면 .husky폴더가 생기고 package.json 파일에 다음과 같은 코드가 추가로 생길 것이다.

{
  "scripts": {
    "prepare": "husky install"
  },
  "devDependencies": {
    "husky": "^6.0.0",
    "lint-staged": "^11.0.0",
  },
  "lint-staged": {
    "*.js": "eslint --cache --fix"
  }
}

2-2. husky 설정하기

&nbsphusky는 .husky폴더에서 설정을 해주면 된다. 하지만 우리는 mrm이 기본 설정을 해준 덕에 따로 설정을 해줄 것이 없다ㅎㅎ .husky 폴더를 보면 pre-commit 파일에 다음과 같은 명령어가 있을 것이다.

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

위의 설정대로 git commit을 하기전에 npx lint-staged 명령어를 실행할 것이다.

2-3. lint-staged 설정하기

lint-staged는 약간 설정이 필요하다.

{
  "lint-staged": {
    "*.js": "eslint --cache --fix"
  }
}

기본적으로는 package.json 파일에 위와 같이 설정이 된다. 만약 .js파일에 eslint만 사용한다면 위처럼 놓고 사용해도 되지만 나는 타입스크립트를 이용할 것이므로 .ts 파일과 .tsx 파일 둘 다 검사할 것 이고 prettier도 사용하므로 다음과 같이 변형해서 사용했다.

{
  "lint-staged": {
    "*.{ts,tsx}": [
      "prettier --write",
      "eslint --fix"
    ]
  }
}

2-4. Test해보기🌻

&nbsp이제 제대로 작동하는지 확인을 해보겠다.

git add . git commit -m 'Test husky & lint-staged'

위의 명령어를 넣으면 다음처럼 나온다면 제대로 동작하는 것이다.

&nbsp위의 사진을 보면 우리가 설정한대로 git commit를 하기 전에 stage 상태에 있는 .ts와 .tsx파일들을 대상으로 eslint --fix와 prettier --write 명령어를 실행하고 있다. 그러다가 eslint 규칙상 에러가 난 부분이 있어 git commit을 못하게된 상황이다. 한마디로 아주 잘 작동한다!!😎

3. 마치며🥳

&nbsp이렇게 husky와 lint-staged 라이브러리를 이용하여 eslint를 강제로 할 수 밖에 없게 설정을 해보았다. 꼭 강제한다는 부분 말고도 내가 따로 eslint를 실행하지 않아도 자동으로 명령어를 실행해준다는 점도 매우 매력적이라고 생각된다.

💡직접 읽어보면 뼈가 되고 살이 되는 출처 👉https://go2zo.github.io/blog/2021/05/23/husky-v6/ 👉https://github.com/typicode/husky/issues/949 👉https://taegon.kim/archives/10276 👉https://dev-syhy.tistory.com/57 👉https://shiningjean.tistory.com/86

ESLint는 문법적으로 문제가 있는 코드를 찾아주는 도구다.

협업 프로젝트를 할 때는 여러사람이 자신만의 규칙으로 코드를 작성한다. 물론 다들 틀리게 코딩을 하는 것은 아니다. 하지만 대부분 다들 다르게 코딩을 하게된다. 본인에게 익숙한 방법으로 ... 이게 바로 문제다.

"아니 코드 잘 돌아가고 빨리 작성하기만 하면 되는거 아니야?"🤨

라고 생각하는 분들도 있겠지만 주관적인 견해로는 옳지 않다. 서로가 일관성없는 코드를 작성하게 되면 타인의 코드의 가독성이 떨어지게 되는 것은 필연적이다. 그것은 이후의 코드 리뷰에서 큰 문제를 발생하게 된다. 내가 쓰는 코드와 생긴게 너무 다르면 코드를 읽는데 시간이 오래 걸리고 오래걸려서 읽는다고 해도 존재하는 오점을 잡아낼 가능성도 떨어지게 된다. 이런 문제를 해결하기 위해서 코딩 컨벤션을 유지시켜주며 추가적으로 문법적인 오류나 안티 패턴, 변수 범위 등을 정적 분석을 통해 런타임 에러를 사전에 발견할 수 있게 도와준다.👍

2. ESLint 사용하기(feat. typescript)

2-1. 패키지 설치하기💻

eslint는 정말로 좋은 협업 라이브러리다. 하지만 git정도로 배우는 것이 어렵다고 생각한다. 최대한 필요한 부분만 간단하게 설명하도록 할께요.

우선 eslint 관련 패키지들 설치하기!

// 타입스크립트관련 ESLint패키지 설치 npm i -D eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser eslint-import-resolver-typescript

// ESLint 서드파티 플러그인 패키지 설치 npm i -D eslint-plugin-react eslint-plugin-react-hooks eslint-plugin-import eslint-plugin-jsx-a11y

// airbnb사 ESLint 환경설정 패키지 npm i -D eslint-config-airbnb

// prettier와 ESLint 충돌방지용 패키지 npm i -D eslint-config-prettier eslint-plugin-prettier

패키지 설명✍️

eslint: 코드의 문법을 검사하는 린팅과 코드의 스타일을 잡아주는 포맷팅 기능 @typescript-eslint/eslint-plugin: TypeScript관련 linting 규칙을 처리하는 플러그인 @typescript-eslint/parser: TypeScript용 ESLint 파서 eslint-import-resolver-typescript: 정확한 에러는 기억이 안나는데 해당 패키지를 설치하지 않으면 에러가 발생했었어요... 나중에 정확한 이유를 기입하겠습니다...ㅜ

eslint-plugin-react: React 관련 린트설정을 지원해줘요 eslint-plugin-react-hooks: React Hooks의 규칙을 강제해주는 플러그인입니다 eslint-plugin-import: ES2015+의 import/export 구문을 지원해줘요 eslint-plugin-jsx-a11y: JSX 내의 접근성 문제에 대해 즉각적인 AST 린팅 피드백을 제공해줘요

eslint-config-airbnb: airbnb사의 코딩규칙을 사용하게 해줘요

eslint-config-prettier: prettier와 eslint의 충돌을 일으키는 ESLint 규칙들을 비활성화 시켜주는 config eslint-plugin-prettier: prettier에서 인식하는 오류를 ESLint가 출력해주게 해줘요

📌 혹시 CRA로 프로젝트를 생성했다면 eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-import, eslint-plugin-jsx-a11y 는 CRA에서 지원해주므로 제외하고 설치해주면 되요!

2-2. ESLint 설정하기🤟

모든 패키지를 설치했다면 이제 설정을 해줘야합니다. 여러가지 방법이 있지만 저는 .eslintrc.json 파일을 생성하는 것을 선호해서 해당 방법으로 진행해볼께요

우선 .eslintrc.json 해당 파일을 프로젝트의 최상위 폴더에 생성해줍니다. 그 이후 아래의 텍스트를 붙여 넣어주시면 됩니다ㅎㅎ

{
  "env": {
    "browser": true,
    "es6": true,
    "node": true
  },
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint", "import"],
  "extends": [
    "airbnb",
    "airbnb/hooks",
    "plugin:@typescript-eslint/recommended",
    "plugin:prettier/recommended",
    "plugin:import/errors",
    "plugin:import/warnings"
  ],
  "parserOptions": {
    "ecmaVersion": 2020,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
  },
  "rules": {
    "linebreak-style": 0,
    "import/no-dynamic-require": 0,
    "import/no-unresolved": 0,
    "import/prefer-default-export": 0,
    "global-require": 0,
    "import/no-extraneous-dependencies": 0,
    "jsx-quotes": ["error", "prefer-single"],
    "react/jsx-props-no-spreading": 0,
    "react/forbid-prop-types": 0,
    "react/jsx-filename-extension": [
      2,
      { "extensions": [".js", ".jsx", ".ts", ".tsx"] }
    ],
    "import/extensions": 0,
    "no-use-before-define": 0,
    "@typescript-eslint/no-empty-interface": 0,
    "@typescript-eslint/no-explicit-any": 0,
    "@typescript-eslint/no-var-requires": 0,
    "no-shadow": "off",
    "react/prop-types": 0,
    "no-empty-pattern": 0,
    "no-alert": 0,
    "react-hooks/exhaustive-deps": 0
  },
  "settings": {
    "import/parsers": {
      "@typescript-eslint/parser": [".ts", ".tsx"]
    },
    "import/resolver": {
      "typescript": "./tsconfig.json"
    }
  }
}

ESLint 설정 옵션 설명✍️

env: 사전 정의된 전역 변수 사용을 정의해줄 수 있어요. 사전 정의된 전역변수를 확인 할 수 있는 Docs를 링크해둘께요.

"env": {
  "browser": true,
  "es6": true,
  "node": true
}

그리고 선언하지 않은 전역변수를 사용할 때 경고하지 않도록, globals를 이용하여 사용자 전역 변수를 추가할 수 있어요.

"globals": {
 "$": true
}

parser: ESLint는 구문 분석을 위해 보통 Espree 파서를 사용해요. 자주 사용되는 파서로는 Babel과 함께 사용되는 babel-eslint, Typescript 구문 분석을 위해 사용되는 @typescript-eslint/parser가 있어요.

"parser": "@typescript-eslint/parser"

plugins: ESLint는 서드파티 플러그인을 지원해요. 플러그인 패키지들을 설치하고, 설치한 플러그인들을 plugins에 추가하여 사용할 수 있어요.

"plugins": ["@typescript-eslint", "import"]

extends: extends는 추가한 플러그인에서 사용할 규칙을 설정해줘야해요 플러그인은 일련의 규칙 집합이며, 플러그인을 추가하여도 규칙은 자동 적용되지 않아요. 규칙을 적용하기 위해서는 추가한 플러그인 중에 사용할 규칙을 직접 추가해줘야 적용되요.

"plugins": ["@typescript-eslint", "import"],
"extends": [
  "airbnb",
  "airbnb/hooks",
  "plugin:@typescript-eslint/recommended",
  "plugin:prettier/recommended",
  "plugin:import/errors",
  "plugin:import/warnings"
],

eslint:all과 eslint:recommended는 ESLint에 기본으로 제공해주고 있어요. 하지만 ESLint는 eslint:all을 프로덕션 용도로 사용하지 않는 것을 권장하고 있어요.

parserOptions: ESLint 사용을 위해 지원하려는 Javascript 언어 옵션을 정의할 수 있어요.

• ecmaVersion: 사용할 ECMAScript 버전을 설정
• sourceType: parser의 export 형태를 설정
• ecmaFeatures: ECMAScript의 언어 확장 기능을 설정
  • globalReturn: 전역 스코프의 사용 여부 (node, commonjs 환경에서 최상위 스코프는 module)
  • impliedStric: strict mode 사용 여부
  • jsx: ECMScript 규격의 JSX 사용 여부

    {
    "parserOptions": {
    "ecmaVersion": 2020,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
    }
    }

rules: ESLint에는 프로젝트에서 사용하는 규칙을 수정할 수 있어요.

• "off" 또는 0: 규칙을 사용하지 않음
• "warn" 또는 1: 규칙을 경고로 사용
• "error" 또는 2: 규칙을 오류로 사용

규칙에 추가 옵션이 있는 경우에는 배열 리터럴 구문을 사용하여 지정할 수 있습니다.

"rules": {
  "eqeqeq": "off",
  "curly": "error",
  "quotes": ["error", "double"]
  "comma-style": ["error", "last"],
}

settings: ESLint 구성 파일에 설정 개체를 추가할 수 있으며, 실행될 모든 규칙에 제공됩니다.

"settings": {
  "import/parsers": {
    "@typescript-eslint/parser": [".ts", ".tsx"]
  },
  "import/resolver": {
    "typescript": "./tsconfig.json"
  }
}

2-3. ESLint 실행하기🚀

이렇게 설정까지 다 해냈다면 이제 잘 작동하는지 확인을 해볼 시간이네요. 터미널에 다음과 같은 명령어를 입력해봅시다.

eslint {파일경로} ex) eslint src/components/atoms/Button/index.ts

만약 eslint 명령어를 사용할 수 없다면 eslint를 전역 설치해주시면 될거에요.

npm i -g eslint

다시 eslint를 실행해보면 에러가 있다면 다음과 같이 나올꺼에요. 해당 에러를 고치려면 직접 고치는 방법과 명령어를 통하여 자동으로 고치는 방법이 있어요.

eslint --fix {파일경로} ex) eslint --fix src/components/atoms/Button/index.ts

eslint 명령어 뒤에 --fix 옵션을 붙이면 발생한 에러를 자동으로 고쳐줘요. 하지만 모든 에러를 고쳐주진 않아요...🥲

3. 마치며

ESLint를 좀 더 자세히 알아보는 시간이 되었던 것 같다. 최재한 양질의 정보를 전달하려 했지만 그러지 못한 부분이 많은 것 같기도하다. 혹시 이 글을 끝까지 읽고 계신 분들한테는 밑에 출처도 한번씩 방문해서 더 좋은 글들을 읽어보시길 추천드립니다

💡직접 읽어보면 뼈가 되고 살이 되는 출처 👉https://velog.io/@kyusung/eslint-config-2#환경env 👉https://velog.io/@xortm854/Typescript-React-Eslint-환경설정-2편-ESLint-Prettier-설정 👉https://eslint.org/docs/user-guide/getting-started 👉https://velog.io/@kmlee95/React-Typescript-eslint-prettier설정 👉https://pravusid.kr/typescript/2020/07/19/typescript-eslint-prettier.html 👉https://overcome-the-limits.tistory.com/entry/협업-ESLint-Prettier-Airbnb-Style-Guide로-코드-컨벤션-설정하기 👉https://tech.kakao.com/2019/12/05/make-better-use-of-eslint/

Prettier는 간단하게 코드 스타일을 관리해주는 도구다.

코딩을 하다보면 혼자서 코딩을 하더라도 코딩이 일관성이 없어진다. 어디서는 ;을 잘 붙어 놓고 어디선 안 붙이고 혹은

for (let i = 0; i < 10; i++)
for (let i=0;i<10;i++)

위 두줄은 같은 것을 의미하지만 육안으로 볼 때 확실히 달라보인다. 이렇게 코드가 일관성이 없다면 내 코드를 읽어도 짜증나는데 남의 코드를 읽거나 남이 이런 내코드를 읽으면 얼마나 화가 날까...🤬

이런 문제를 해결하기 위하여 태어난 것이 바로 Prettier이다. 나는 혼자 프로젝트를 할 때도 자주 사용하지만 다른 사람들과 협업을 할 때 더 빛을 발한다. 확실히 이름처럼 코드가 더 이뻐지는 것을 느낄 수 있을 것이다.🌻

2. Prettier 사용법💻

우선 우리 프로젝트에 Prettier를 설치해야한다.

npm i -D prettier

(저는 npm 유저여서 npm 기준으로 설명을 진행할께요...😅)

그 후에 prettier를 설정하기 위해 최상위 디렉터리에 .prettierrc파일을 만들어주세요. 그럼 해당 파일에서 여러가지 설정이 가능하답니다.😁 그러면 제가 자주 사용하는 것들 위주로 설명을 드릴께요.

singleQuote: 문자열 입력시 " 를 쓸지 ' 를 사용할지 설정할 수 있어요. 저는 ' 를 사용하기에 true로 설정해 놓았습니다.

semi: 세미콜론(;) 사용에 관한 설정이에요. 저는 사용하므로 true 로 놓고 사용해요.

tabWidth: 들여쓰기의 크기를 정할 수 있어요. 저는 2칸으로 놓고 써요. 4칸으로 놓고 쓰면 들여쓰기가 중첩될 시에 코드 뒷부분이 안보이는 경우가 생기더라구요....ㅜ

trailingComma: 객체 또는 배열이 여러줄로 구성되어 있으면 다음과 같이 맨 마지막 줄에 쉼표를 붙여줄지 설정할 수 있어요.

const object = {
  a: 1,👈
  b: 2,👈
};

none 이면 쉼표를 붙이지 않고, es5 이면 객체, 배열을 사용하게 될 떄 쉼표를 붙이고, all 이면 함수를 사용 할 때 인자를 전달 할 때도 쉼표를 붙입니다.

printWidth: 줄 바꿈할 폭의 길이를 설정해줄 수 있어요.📏

저는 아래와 같이 설정해 놓고 사용합니다.

{
  "singleQuote": true,
  "semi": true,
  "tabWidth": 2,
  "trailingComma": "all",
  "printWidth": 80
}

제가 주로 사용하는 옵션들 말고도 많이 있으니 Docs를 링크하도록 할께요.😉

3. 마치며

prettier는 정말로 코드의 질을 높여주는 것 중에 가장 가성비가 좋다. 이렇게 간단한데 코드는 정말로 43.1324배는 깔끔하고 이뻐진다. 정.말.로. 진심이다. 아직 사용하지 않는 분들이라면 꼭 한번 사용해보기를 추천한다.

💡직접 읽어보면 뼈가 되고 살이 되는 출처 👉https://react.vlpt.us/basic/27-useful-tools.html 👉https://velog.io/@kyusung/eslint-prettier-config 👉https://prettier.io/docs/en/options.html