🗓 항해 99 3기에서 10/4 ~ 10/9 동안의 4주차 회고록

이번 주 화요일까지는 심화주차 강의를 들었고, 수요일부터 과제를 시작했다. 과제를 시작하기에 앞서 고민이 많이 되었다. 이왕하는거 매운맛 과제인 캘린더를 만들어보고 싶었지만, 심화주차 강의 내용도 제대로 이해하지 못하고 새로운 것을 도전해도 될까 하는 생각이 들었다. 그래서 강의 내용을 복습하는 차원에서 순한맛 과제를 시작했다. 그러다가 멘토님하고 튜터님께서 게더에 찾아오셔서 많은 이야기를 해주셨는데 나와 같은 고민을 하시는 분들한테 지금은 그냥 하고 싶은 걸 한번 해봐도 괜찮은 시기라고 말씀해주셔서 그때부터 다시 고민이 되었다. 결국에는 새로운 것을 만들어보면서 얻는 것도 있을것이라고 생각이 들어서 수요일 저녁부터 캘린더를 만들기 시작했다.

생각보다 캘린더 과제는 어렵지 않았다. 나같은 경우에 fullcalendar 패키지에 요구사항 기능만 추가했기 때문에 그랬을 수도 있다. 그치만 기능자체도 순한맛 과제보다 훨씬 적었던 것 같다. 캘린더를 다 만들고나서 든 생각은 심화주차 강의에서 중요하게 생각했던 로그인,회원가입,무한스크롤 같은 기능이 캘린더에서는 안쓰였기 때문에 따로 중요 기능에 대한 내용을 복습을 해야겠다는 것이였다..!

오늘은 아주 늦게 일어나서 심화강의에서 firebase의 Authentication 기능을 이용해서 로그인,회원가입 기능을 구현한 부분을 쭉 정리를 해보았다. 아직 쿠키, 세션 스토리지에 대해 완벽히 이해를 한 상태는 아니어서 자기전에 더 공부해야겠다.

내일부터는 처음으로 백엔드분들과 협업해서 프로젝트를 진행한다. 백엔드와 어떻게 데이터를 주고받는지도 모르는데 과연 잘 할 수 있을까 싶고, 프론트엔드 팀원분들과도 합이 잘 맞아야할텐데 걱정도 되지만 재미있을 것 같다...!

📌 이번주 핵심정리

1. 리액트와 전역 상태 관리

리액트에서 상태란?

props는 컴포넌트간 전달 되지만 state 는 컴포넌트 안에서 관리되고 시간이 지나면서 바뀌는 동적인 값을 상태(state)라고 부른다.

리액트 상태는 크게 1) 범위 2) 역할로 나눠 볼 수 있다.

1. 범위의 측면

   state 가 몇몇 컴포넌트에서 국한되서 영향을 주는 지역 상태 와 많은 컴포넌트에 영향을 주는 전역 상태 로 나눌 수 있다.

2. 역할의 측면

   어플리케이션의 인터렉티브한 부분을 컨트롤하는 UI 상태 , 서버로부터 데이터를 가져와 캐싱 해놓는 서버 캐시 상태 , Form의 CRUD 등 데이터를 다루는 Form 상태 , 브라우저에 의해서 관리되고 새로고침해도 변함 없는 URL 상태 등이 있다.

리액트 상태 관리

기존의 웹 프론트엔드 상태 관리는 MVC(Model-View-Controller) 패턴 을 써서 UI관리를 했었다.

• MVC 패턴이란?
  

👉 개발할 때 Model, View, Controller 3가지 형태로 구분하여 개발하는 소프트웨어 개발 방법론을 말한다.

MVC 패턴이 갖는 양방향 데이터 흐름은 UI 인터랙션을 관리하기 불가능한 구조가 되었고, 2013년에 단방향 데이터 흐름 을 갖는 리액트가 나오게 된다. 초반에는 전역상태관리 라이브러리가 존재하기 않았기 때문에 상위 컴포넌트에서 하위 컴포넌트로 props 를 넘겨주면서 상태관리를 했다. 어플리케이션의 규모가 커지면서 컴포넌트의 갯수도 많아지면서 state를 전달하기 위해서 관계없는 컴포넌트까지 지나가면서 state를 props로 전달하는 상황이 생기게 되었다. 이런 문제를 Prop Drilling 이라고 한다.

2014년에 페이스북은 그 대안으로 단방향으로 데이터가 흐름이 있는 Flux 패턴 을 공개했다.

Flux | 사용자 인터페이스를 만들기 위한 어플리케이션 아키텍쳐

Flux 패턴에서 View는 MVC 패턴과 달리 데이터를 변경시키지 않고 Action을 넘겨준다. Action은 반드시 Dispatcher를 지나게 되고 Dispatcher를 통해서 데이터 변경이 일어나고 View는 변경된 데이터를 Store를 통해서 전달받는다.

2015년에는 React + Flux 의 구조에 Reducer 를 결합한 Redux=Red(ucer) + (Fl)ux 가 등장했다. Redux는 리액트의 Prop Drilling 문제와 여러 복잡해지는 상태 공유에 따른 컴포넌트간 의존성 문제를 해결할 대안으로 떠올랐다.

전역 상태 관리

• Redux의 한계 Redux는 안정적인 상태 유지를 위해서 3가지 원칙을 요구한다.

  1. 애플리케이션의 모든 상태는 하나의 저장소 안에 하나의 객체 트리 구조로 저장된다.

  2. 상태는 읽기 전용이어야 한다. (오직 Reducer에서만 상태를 변화시킬 수 있다.)

  3. 변화는 순수 함수로 작성되어야 한다.

     Flux 패턴을 이용해서 단방향 흐름으로 안정적인 상태 운용이 가능하지만 원하는 상태와 기능추가를 위해서는 dispatch를 위한 Action, 상태 변화를 위한 reducer, 컴포넌트에서 state를 가져다 쓰는 부분 모두 손봐야 하기 때문에 코드의 복잡도가 심화될 수 있다. Redux Toolkit 을 사용해서 조금 더 편하게 전역 상태 관리를 할 수도 있다.

• Context API 간단한 대안으로 리액트 Hooks 중 하나인 Context API를 활용해서 전역상태 관리를 할 수 있다. Context는 전역 데이터를 Context에 저장한 후, 데이터가 필요한 컴포넌트에서 해당 데이터를 불러와 사용할 수 있다.
  

• Recoil 페이스북에서 복잡한 UI를 대상으로 전역상태 관리를 위한 해결방법으로 React만을 위한 상태 관리 라이브러리를 소개하였다. Recoil에서는 Atom이라는 작은 데이터 조각을 만들어서 해당 state 변화 시에 이를 참조하는 컴포넌트들만 리렌더링을 시키는 단순한 로직으로 되어있다.
  

2. CSS 라이브러리와 리액트

👉 리액트에서 컴포넌트를 스타일링하는 가장 기본적인 방법은 css 파일을 만들어서 컴포넌트에서 import해서 사용하는 것이다. 이 이방법 외에도 컴포넌트를 스타일링할 때 다른 도구들을 사용하면 훨씬 편하게 스타일링할 수 있다.

1) Sass

• Sass(Syntactically Awesome Style Sheets: 문법적으로 짱 멋진 스타일시트)는 CSS pre-processor로서, 복잡한 작업을 쉽게 할 수 있게 해주고, 코드의 재활용성을 높여줄 뿐 아니라 코드의 가독서을 높여주어 유지보수를 쉽게 해준다.
• 두가지 확장자(.scss/.sass)를 지원한다.
• Sass를 사용하면 스타일 파일에 유용한 문법을 사용해서 컴포넌트 스타일링 생산성을 높여줄 수 있다.
• Sass
  

2) CSS Module

• 리액트 컴포넌트를 스타일링 할 때 CSS Module을 사용하면, CSS 클래스가 중첩되는 것을 완벽히 방지할 수 있다.
• CSS 파일의 확장자는 .module.css 로 하면 된다.
• 리액트 컴포넌트에서 해당 CSS 파일을 불러올 때 CSS 파일에 선언한 클래스 이름들이 고유해진다.
• 클래스 이름에 대하여 고유한 이름이 만들어지기 때문에, 실수로 CSS 클래스 이름이 다른 관계 없는 곳에서 사용한 CSS 클래스 이름과 중복되는 일에 대해 걱정하지 않아도 된다.
• 참고로 , CSS Module 은 Sass에서도 사용할 수 있다. 확장자를 .module.css로 바꿔주면 된다.
• 레거시 프로젝트에 리액트를 도입하게 될 때, 또는 클래스 이름 짓는 규칙을 정하기 힘들거나 번거로울 때 사용하면 편리하다.
• CSS Module

3) styled-components

• 이 기술을 사용하면 JS안에 CSS를 작성할 수 있다.
• Tagged Template Literal 문법을 기반으로 작동한다.
• styled-components