[인프런 워밍업 스터디 클럽 1기 프론트엔드] 3주차 발자국

학습 내용

Test Driven Development
실제 코드를 작성하기 전에 테스트 코드를 먼저 작성한다.
테스트 코드를 작성한 후 그 테스트 코드를 Pass할 수 있는 실제 코드를 작성한다.
- 장점
  - 많은 기능을 테스트하기 때문에 소스코드에 안정감이 부여된다.
  - 실제 개발하면서 많은 시간이 소요되는 부분은 디버깅 부분인데, TDD를 하면 디버깅 시간이 줄어들고 실제 개발 시간도 줄어든다.
  - 소스코드 하나하나를 더욱 신중하게 짤 수 있기 때문에 깨끗한 코드가 나올 확률이 높다.
리액트 테스팅 라이브러리
- React 구성 요소에 대한 테스트 작업을 위한 API를 추가하여 DOM Testing Library 위에 구축된 Test 라이브러리
- DOM Testing Library란 Dom 노드(Node)를 테스트하기 위한 매우 가벼운 솔루션
- CRA로 생성된 프로젝트는 기본적으로 React Testing Library를 지원한다.
- Enzyme이 구현 주도 테스트를 지원한다면, React Test Library는 행위 주도 테스트를 지원한다.
  - 구현 주도 테스트: 어떤 문자, 태그를 사용해서 구현했는지
  - 행위주도 테스트: 어떠한 이벤트를 발생시켰을 때 화면이 어떻게 변화가 되는지
Jest
- 페이스북에서 만든 테스팅 프레임워크
- 최소한의 설정으로 동작하며 테스트 케이스를 만들어서 애플리케이션 코드가 잘 돌아가는지를 확인해준다.
- 주로 단위테스트를 위해 이용한다.
  
  붉은 글씨에 해당되는 문자열이 포함된 파일을 테스트 파일로 인식
- 파일 구조&사용법
  - describe: 여러 관련 테스트를 그룹화하는 블록을 만든다.
  - it: 개별 테스트를 수행하는 곳. 각 테스트를 작은 문장처럼 설명한다.
  - expect(): 값을 테스트할 때마다 사용된다. matcher와 함께 사용된다.
  - matcher(): 다른 방법으로 값을 테스트하기 위해 사용한다.
```
test('two plus two is four',()=>{
	expect(2 + 2).toBe(4)
}
```
- render(): DOM에 컴포넌트를 렌더링하는 함수. 인자로 렌더링할 React 컴포넌트가 들어간다.
쿼리 함수
- 페이지에서 요소를 찾기 위해 테스트 라이브러리가 제공한느 방법.
- 여러 유형의 쿼리(get, find, query)가 있으며, 이들 간의 차이점은 요소가 발견되지 않으면 쿼리에서 오류가 발생하는지 또는 Promise를 반환하고 다시 시도하는지 여부이다.
NextJS
- React의 서버 사이드 렌더링을 쉽게 구현할 수 있게 도와주는 간단한 프레임워크.
- 리액트로 개발할 때 SPA를 이용하여 클라이언트 사이드 렌더링을 하기 때문에 좋은 점도 있지만 검색엔진 최적화(SEO) 면에서는 좋지 않다.
  - 클라이언트 사이드 렌더링을 하면 첫 페이지에서 빈 html을 가져오고 js 파일을 해석해 화면을 구성하기 때문에, 포털 검색에 거의 노출될 일이 없다.
- Next.js는 Pre-Rendering을 통해 페이지를 미리 렌더링하고 완성된 HTML을 가져오기 때문에 사용자와 검색엔진 크롤러에게 바로 렌더링된 페이지를 전달할 수 있다.
Server Side Rendering
- 클라이언트 대신 서버에서 페이지를 준비하는 원리
- 기존 리액트에서는 CSR을 하기 때문에 서버에 영향을 미치지 않고, 서버에서 클라이언트로 응답해서 보낸 html도 거의 비어있다.
  ⇒ 이 방식은 서버에서 데이터를 가져올 때 지연 시간 발생으로 UX 측면에서 좋지 않을 수 있다.
  ⇒ 검색 엔진에 검색 시 웹 크롤링이 동작할 때 내용을 제대로 가져와 읽을 수 없기에 검색엔진 최적화에 문제가 된다.
Next.js 앱 생성 방법
```
npx create-next-app [경로]
```
Next.js 프로젝트 구성
- pages: 이 폴더 안에 페이지들을 생성한다.
  - 처음엔 index.tsx가 “/” 페이지로 매핑된 상태
  - app.tsx는 공통되는 레이아웃을 작성한다. 모든 페이지에 공통으로 들어가는 걸 넣어주려면 여기에 넣어주면 된다.(헤더, Footer 등)
    ⇒url을 통해 특정 페이지에 진입하기 전 통과하는 일종의 인터셉터 페이지.
- public: 이미지같은 정적 에셋들을 보관한다.
- styles: 스타일을 처리해주는 폴더. 모듈(module) css는 컴포넌트 종속적으로 스타일링하기 위한 것으로, 확장자 앞에 module을 붙여주어야 한다.
- next.config.js: Nextjs는 웹팩을 기본 번들러로 사용한다. 그래서 웹팩에 관한 설정들을 이 파일에서 해줄 수 있다.
Pre-rendering
- 모든 페이지를 위한 HTML을 클라이언트 사이드에서 자바스크립트로 처리하기 전, ‘사전에’ 생성하는 것.
- 이 pre-rendering 덕분에 SEO 검색엔진 최적화가 좋아진다.
- 브라우저에서 JavaScript를 사용하지 못하게 해놓으면 Pre-Rendering이 이루어지는지, 아닌지 확인할 수 있다.
Data Fetching
- 리액트에서 데이터를 가져올 때는 useEffect 안에서 가져온다.
- Next.js는 다음의 세 가지 방법을 통해 데이터를 가져온다.
  - getStaticProps: Static Generation으로 빌드(build)할 때 데이터를 불러옴(미리 만들어줌)
    - 사용하는 경우
      - 페이지를 렌더링하는 데 필요한 데이터는 사용자의 요청보다 먼저 build 시간에 필요한 데이터를 가져올 때
      - Headless CMS에서 데이터를 가져올 때
      - 데이터를 공개적으로 캐시할 수 있을 때(사용자별 아님)
      - 페이지가 미리 렌더링되어야 하고 매우 빨라야 할 때
  - getStaticPaths: static generation으로 데이터에 기반하여 pre-render 시 특정한 동적 라우팅 구현(pages/post/[id].js)
  - getServerSideProps: 서버 사이드 렌더링으로 요청이 있을 때 데이터를 불러옴
    - 사용하는 경우
      - 요청할 때 데이터를 가져와야 하는 페이지를 미리 렌더해야 할 때 사용
      - 서버가 모든 요청에 대한 결과를 계산하고, 추가 구성없이 CDN에 의해 결과를 캐시할 수 없기 때문에 첫번째 바이트까지의 시간은 getStaticProps보다 느리다.
type assertion(타입 표명)
- 시스템이 추론/분석한 타입 내용을 우리가 얼마든지 바꿀 수 있는데, 이 때 사용되는 메커니즘이 type assertion이다.
- type assertion을 사용하면 값의 type을 설정하고 컴파일러가 이를 유추하지 않도록 지시할 수 있다.
```
var foo = {};
foo.bar = 123; //오류
```
```
interface Foo{
	bar: number;
	bas: string;
}

var foo = {} as Foo;
too.bar = 123;
foo.bas = 'hello';
```
- 타입 표명은 as Foo, <Foo> 두 가지 방식으로 표현 가능한데, 리액트에서는 JSX문법과 겹치기 때문에 <Foo>보다는 as Foo를 공통적으로 사용하는 것이 권장된다.

학습 회고

짧다면 짧고, 길다면 길었던 인프런 워밍업 클럽 1기 활동이 끝났다. 3주동안 30여 시간의 강의를 듣는것은 생각보다 만만치 않았고, 깊은 공부를 하기엔 조금 템포가 빠르지 않았나 싶다. 물론 이건 내가 병행하고 있는 일들이 많아서 상대적으로 그렇게 느껴진 것 같기도 하다.

이번 인프런 워밍업 클럽 활동을 통해 새로운 지식을 얻었을 뿐만 아니라 미션을 통해 내 역량을 확인하고 앞으로의 학습 방향성에 대해 고민해볼 수 있어 좋았다.

이번 주차 학습 과정에서 Next.js를 처음 접해보았는데, 미션에서 활용하지는 못해서 나중에 다른 프로젝트로 Next.js를 도입해보고 싶다.

미션 해결과정

노트 앱 미션을 구현하는 과정 중 노트 정렬 기능을 구현하는 데 삽질을 했던 게 기억이 난다.

분명 콘솔을 통해 정렬 로직이 잘 동작하는 것을 확인을 했는데, 실제로 노트 정렬 순서가 업데이트되지 않아서(렌더링되지 않아서) 고생을 했는데, 문제 원인은 정렬 기준에 따른 분기문(switch문)에서 case별로 break를 걸어주지 않아 제대로 적용이 안된 것이었다.

switch문에서 break를 쓰는 건 기본 중의 기본인데, 이런 실수를 한 게 어이가 없었다.

디버깅이란 언제나 참 어려운 것 같다.

미션 회고

난이도 상 미션이라 그런지 자바스크립트 미션에 비해 구현해야 할 내용이 상당히 많아서 꽤 고생스러웠던 것 같다.

특히, 상태를 어떻게 관리할지 설계하는 과정이 무척 어렵게 느껴졌다.

기능을 구현하는 것은 쉽지만, 코드를 깔끔하고 수정하기 쉽게 만드는 건 정말 어려운 것 같다.