원티드 프리온보딩 수업정리 #2 0802

---

일과 공부는 다르다.

지식을 쌓으려면 공부를 해야한다.

 

강의 및 서적 추천 !

• 리액트의 아버지ㅋㅋ-udemy
• 벨로퍼티님 강의
• 책 - 실전 리액트 프로그래밍 추천스

클래스, hooks에 대한 명확한 이해가 필요

그 회사의 CSS의 클래스명 어떻게 썼는지 분석도 필요. 눈에 익숙하다.

 

Case

• ROUTE도 상수다. 이런 식으로 빼는 것 좋다!
•  
• 
• 파일 컴포넌트이름 - 카멜케이스 + 대문자 시작
  • js로만 해도 누구나 jsx로 된다는건 알 수 있음. 굳이 안써도됨
• Page 하위의 이름은 굳이 뒤에 Page 안 붙임- 왜 ? 이미 Page라는건 알 수 있으니
• 개발자도구의 어느 파일에서 에러가 있다고 확인할 때 파일명만 나옴 - 마우스 hover하면 경로까지 보이긴 하지만, 디버깅 편하게 하려고 붙이는 경우도 있긴 함.
• index.js에 컴포넌트를 작성하는 케이스가 있었는데 디버깅하기 좀 어려울 수 있음 -> Home/index.js , Home/Home.js 이 두개로 index.js에서 home을 export만 함. 에러 발생시 Home.js라고 디버깅으로 확인할 수 있음. 그럼 컴포넌트 명과 같은 파일을 두고 전체 모든 컴포넌트를 export하는 index.js를 하면 되나 ?

_isMounted가 필요 없다.

didMount는 우리가 호출할게 아니라 호출 당하는것, 그리고 didMount이 후 lifecycle method가 없음. 그래서 async를 써도 side effect가 없음. api는 항상 didMount에서 호출

아래는 사실 async가 필요 없는 코드다, ? 비동기로 데이터를 호출해오는데 await없이 setState를 어떻게 초기화 할 수 있는 것인지 ??

궁금한 사항

 

 

관심사의 분리

• 라우트를 하는 역할은 그 역할만 하도록 한다. 한 페이지에서 데이터를 fecth해와도 라우트를 하는 부분은 그것만 하도록 한다. 각 컴포넌트에서 api를 불러오도록 하는게 낫다.

 

 

React에서 전역변수를 쓸일은 거의 없음.

let으로 선언된 값은 전역변수로 되어있음. Side effect존재가능성

watch변수명 변경. 덜 명확함

React에서 DOM을 직접 접근할 일을 없애라. 진짜 부득이하면 그때 ref.

 

 

Class / Functional

Functional

• 코드가 짧아짐. 가독성 업, 유지보수 쉬워짐. 페북피셜) 클래스형이 엄청 복잡한 경우 side effect있을수도 있어. 새로 만드는 프로젝트는 함수형으로 하셈.. ! 그런데 회사에 너무 legacy가 많기에 이것도 알긴 알아야함.
• 관심사를 모을 수 있음.

관련 면접 질문

답변 : 이론 한 두줄, 실제로 써봤는데 이건 이랬고 저건 저렇더라..

• Life cycle 순서와 역할
• life cycle 중 써본 method 뭐가 있음?
• 함수형 vs 클래스형 컴포넌트의 차이 ?

life cycle 링크

 

 

hooks

• useState
• useEffect - DidMount, DidUpdate, WillUnmount역할
  • 의존성배열의 값이 많아지면 많아질수록 성능이 --
  • 그럴 때 사용하는게 useReducer,,
• useRef
  • 라이프 사이클동안 유지되는 값 = 멤버 변수
  • DOM 요소 접근

다음시간에 알아볼 (근데 미리 알아볼 ~)

• useReducer
• useCallback
• useMemo

 

 

FrontEnd Libraries

• 쓰라고 했던 라이브러리 아니면 왠만해선 과제에서 쓰지말기
• ui라이브러리도 마찬가지 material, bootstrap, ant-d, etc..
• 리액트 써야되는 이유 (이전 것 보충)
  • 리액트도 라이브러리 !== 프레임워크
  • 라이브러리는 잘 갖다 쓰는게 중요함
• 라이브러리 선정 가이드
  • top을 먼저 확인
  • npm 확인 - weekly download, 마지막 배포, issue 수 등을 체크. 얼마나 활발히 유지되는지 확인하기
  • docs 확인 및 사용해보기
  • MIT인지,, License확인하기
  • library issue확인하기 <- 실무에서 라이브러리 많이 쓰면 쓸수록 안좋은 이유. 확인할게 너무 많아짐
  • 실무에서 라이브러리를 적용하려면,,
    • 회사에서 적용하려면 사용할 근거가 필요함.
    • 왜 써야하는지, 어디까지해봤고, 대체할 라이브러리 몇개고,, 등의 엄격한 라이브러리 선정과정

 

 

Agile

너무 중요한 애자일

나무, 그네 이야기

고객이 원하는 것으로부터 각 직무마다 이해하는 바가 다 달라서 생기는 과정상의 오류

개발방법론에 대한 얘기..

Waterfall,,,

• 배포주기가 잦지않은 SI에서 주로 사용되는 방법으로 알고 있음.
  • 그러기에 git아니고 svn쓰는 것도 그 이유에서 일 것..

Scrum,,,

• Sprint : 기능 개발의 한 cycle
• Planning Meeting : 앞으로 과제기간동안 뭐할 건데.. (미팅의 목적을 두어야함 : 기능분담인지, 구현 디테일 논의인지..)
• Daily Standup : 나 지금 뭐하고있고 뭐 할 예정이고, 뭐 때문에 못하고 있다.(평상시에 소통할 것 이 때 많이 얘기하는것은 금물) 라고 팀원들에게 공유, ! 짧게 짧게 !
• Retrospective Meeting: 다음엔 어떤식으로 하면 좋겠다 회고

팀이 모여서 각 일자별로 일정을 산출해야함.

각자 할 수 있는 부분을 계속해서 merge해서 만들며 주기적인 meeting을 해야함.

 

 

과제

키워드

• 권한 관리 : 권한에 따라 보이는 메뉴가 다름 < 어떤식으로 어디다가 할 것인지? > 전체 컴포넌트에서 필요할 수 있는 권한
• 주소 library (kakao - daum)사용하기
• Table Component - 깔끔하게 만들기 어려움 <고민이 많이 필요함>
• 입력 : 개발패턴을 보기에 중요한 부분
  • 신용카드 : validation check, 4개입력시 다음으로 넘어가는 등..편의성 ++
• 팝업 : 남들도 쓸 수 있게 만들기 <-팝업인가 모달인가 ?-> 라이브러리로는 portal을 쓴다?

수 1차<점수평가 X>, 금 2차 <최종 dead line>

4회차 과제 < 토요일 오후 2시 공개 > 미리해도 되고, 다음주 월요일 과제로 하려고 함 <수요일 제출이겄넴>

• 팀별 레포 하나씩 만들기
• 팀 meeting log 공유
• 배포 필수