[프리온보딩코스 세션 회고 #3] React Foundation (2)와 두 번째 기업 과제 리뷰

8/2 (월) [React Foundation 2]

세션 내용

• React: Functional/Class Component, React Hooks, Event 등
• 프론트엔드 라이브러리 선정 가이드
• 애자일 개발

---

0. React 학습 가이드

💡 리액트 초보라면?

- 영어 잘하는 경우: 🔗 유데미 강의

- 한국어로 된 좋은 강의는 🔗 인프런

- 책 추천 : <리액트를 다루는 기술> - 김민준 저.

💡 리액트 경험이 있다면!

- 책 추천 : <실전 리액트 프로그래밍> - 이재승 저.

1. 두 번째 기업 과제 Review

1.1 Routes는 상수로 작성하면 좋다!

앞으로는 두 번 이상 썼다! 하면 그냥 무조건 상수로 빼자! 유지보수를 위해서!

1.2 URL 설계

1.3 컴포넌트 파일은 일반 파일과 구분 짓기 위해 항상 대문자로 파일을 시작한다! 또, 확장명으로 jsx까지는 안 써도 된다. CRA를 할 때 js 파일이 jsx를 포함한다고 인식하기 때문!

1.4 Class Component의 라이프 사이클 순서

constructor → render → componentDidMount → componentDidUpdate 순

API 호출은 거의 componentDidMount에서 한다.

1.5 하나의 함수에는 하나의 역할만! 하나의 모듈에는 하나의 작업만! 관심사를 분리해야 한다.

💡 모듈?
리액트에서 모듈은 하나의 파일로 생각하면 된다.

1.6 !연산자를 활용하자

1.7 리액트 모듈 내에서 전역 변수를 쓸 일은 거의 없다!

1.8 리액트에서는 DOM에 직접 접근할 일이 거의 없다!

1.9 컨벤션이 고민이라면?

🔗 에어비앤비 자바스크립트 스타일 가이드 참고하기!

2. 클래스형/함수형 Component

2.1 왜 함수형인가?

클래스형보다 함수형이 훨씬 코드가 간결하고, 로직의 재사용이 쉽다! 유지보수에 좋고, 가독성 또한 좋다. 또한 리액트 측에서도 공식적으로 함수형을 적극 지원한다고 밝혔으며, 물론 클래스형을 지속적으로 지원하나 복잡한 코드의 경우 어쩌면 side effect가 발생할 수 있다고도 함! 그렇기 때문에 앞으로 새롭게 개발을 하게 되는 경우에는 무조건 함수형 컴포넌트로 코드를 작성하는 게 맞다!

2.2 그렇다면 왜 클래스형도 공부해야할까?

레거시 코드 때문! 신입이 하는 일 중 대부분은 회사의 기존 레거시 코드들을 읽고 공부하는 일인데, 리액트의 경우 클래스형 컴포넌트로의 개발이 꽤 오랜 시간 지속되어 왔기 때문에 클래스형 컴포넌트도 무조건 알긴 해야 한다! 그렇지만 다 공부할 필요는 없고, 라이프사이클만 이해해도 된다! 🔗 라이프 사이클 메소드 다이어그램

✅ 함수가 다시 렌더 되는 경우는 오로지 두 가지!

1. state가 변경되었을 때
2. props가 변경되었을 때

리액트에서 가장 중요한 것은 DOM 조작을 줄이는 것! 즉, 렌더가 최대한 적게 되어야 하는데, 그러기 위해서는 state 변화를 최소화하거나 props 전달에 대해 고민해보기! 

2.3 관련 면접 질문

• 리액트 라이프사이클의 순서와 역할에 대해 설명해주세요.
• 라이프사이클 중 써본 메소드에 대해 설명해주세요.
• 함수형 컴포넌트와 클래스형 컴포넌트의 차이에 대해 설명해주세요.

💡 면접 답변 꿀팁!
이론만 말하고 그치는 것이 아닌, 그 이론에 대한 나의 경험까지 녹여낼 수 있어야 한다! 

2.4 함수형 컴포넌트의 Hooks!

• useState: 컴포넌트 상태 관리를 위한 Hook
• useEffect: 클래스 컴포넌트의 라이프사이클과 동일한 역할을 하는 Hook
  componentDidMount, componentDidUpdate, componentWillUnmount의 역할을 함
  → 의존성 배열이 길어지게 되면 성능에 좋지 않고, 그런 경우 useReducer를 사용해야 한다!
• useRef: DOM의 특정 요소에 접근을 한다거나 유지되는 값(class의 멤버 변수 역할, 즉 컴포넌트가 변함없이 항상 가지고 있는 값)을 사용하고자 사용하는 Hook(그렇게 많이 사용되지는 않음)

3. 프론트엔드 라이브러리 선정 가이드

과제를 할 때는 라이브러리 사용을 최대한 지양해야 한다! 회사가 궁금한 것은 우리의 코딩 실력이지, 라이브러리로 이미 잘 만들어진 기능들을 활용하는 것이 아니다! 물론 라이브러리를 잘 활용하는 것도 중요한 능력이지만, 과제를 할 때에 있어서는 라이브러리 사용을 최대한 지양하자!

💡 라이브러리와 프레임워크의 차이?
프레임워크는 어쨌든 뼈대가 존재하고 하라는 대로 해야 하지만, 라이브러리는 우리가 사용할 수 있게 여러 가지 메소드를 제공하고 개발자가 자신의 코드에 맞게 잘 가져다 쓰면 됨(Angular는 프레임워크, React는 라이브러리, Vue는 약간 짬뽕..)

3.1 라이브러리 선정하는 팁!

1. 사용하고자 하는 라이브러리를 구글에서 검색한다.

2. npm 사이트에서 얼마나 활발한지 확인한다.

3. 실제 개발된 라이브러리의 Github 레포지토리를 찾아가서 문서가 잘 되어 있는지, issue 탭 들어가서 내가 필요한 정보들이 있는지 등등을 확인한다.

→ 이렇게까지 해야 하는 이유는, 어쨌거나 라이브러리도 개발자가 만든 것이기 때문에 만약 에러가 있는데 고쳐주지 않는다면 그 에러를 내가 해결해야 하는 상황이 생길 수도 있고, 웹 생태계는 계속 발전하는데 반면 그 라이브러리의 업데이트는 멈춰있다? 그러면 새로운 라이브러리를 찾아서 바꿔줘야 하는 등의 이중으로 작업해야 하는 일이 생길 수도 있으니 처음에 선정을 잘해야 한다!

3.2 실무에서 라이브러리를 적용하려면?

라이브러리를 왜 써야 하는지, 어디까지 해봤는지, 뭐가 문제인지, 대체할 라이브러리가 몇 개인지에 대해서 보고를 하고 사용을 해야 한다.

4. 애자일(Agile)

4.1  스크럼(Scrum)

애자일 개발 방법론 중 하나이고, 상호 점진적 개발 방법론을 의미한다.

4.2 스프린트(Sprint)

애자일 개발의 한 사이클을 스프린트라고 한다. 구현 사항의 완성을 목표로 정한 시간을 한 사이클이라고 생각하고, 그거를 스프린트라고 말한다!

4.3 플래닝 미팅(Planning Meeting)

스크럼 팀원 전체가 모여 함께 계획을 수립하는 미팅을 말한다. 기능 어떻게 할지에 대한 논의와 어떻게 나눠서 작업할지에 대한 논의가 필요하다.

4.4 데일리 스탠드 업(Daily Standup)

매일 만나서 무엇을 작업하고 있는지, 오늘은 무슨 작업을 할 예정인지, 현재 이 작업에서 이러한 문제를 겪고 있다든지, 이 세 가지 이야기를 서로 공유해야 한다. 만약에 못 하고 있는 것이 있다면 왜 못 하는지에 대해서 생각하고 해결하기 위한 노력을 해야 함! 또한 데일리 스탠드 업은 말 그대로 서서 짧게 하고 끝내는 미팅이기 때문에 길어지면 안 된다!

4.5 회고 미팅(Retrospective Meeting)

이번 프로젝트를 통해서 배운 것이 무엇이고, 힘들었던 것은 무엇이며, 다음에 다시 애자일을 한다면 어떤 방식으로 해야 할지에 대한 회고를 가지는 시간!