대표님 코드리뷰 감사합니다 : )
컴포넌트 명이랑 라우트 명이랑 일치시킨다.
App.js
각자의 페이지에서 진행하다보니, UI를 확인하는 용도로 진행해서
라우트명도 뒤죽박죽 결국엔 규모가 커지면 보기조차 어려워질 경우가 생긴다.
생각없이 라우트를 사용했다면,
대표님께서 피드백을 주신 후에는 라우팅 설계가 우선시 되어야된다는걸 알게되었다.
현업에서는 설계부분에 있어 더 신경써야한다.
기존에 프로젝트에서는 각자의 페이지에서 view 를 보이기 위해 index.js 처럼 라우트를 사용했다면,
라우트 부분에서 미리 설계한 후 각각 페이지를 분담.
(컴포넌트명이랑 라우트 명이랑 동일하게)
관습적으로 스탯과 useEffect는 넣어준다.
default값으로 습관적으로 넣어주도록 하자.
마찬가지로 규모가 커지게 된다면 시간이 오래 걸린다.
RN 같은 경우엔 네비게이션을 기본 베이스로 세팅.
작업에 들어갈 경우에 우선순위
🥇 일단 라우팅 먼저가 1순위
라우팅 기본베이스 잘 깔린 후,
View 페이지 분석
내가 만든 컴포넌트가 어디에 위치했는지(설계방면)
데이터 props로 공유하는지, 부모.자식관계에 공유하는지 확인.
Compoents 설계
상태관리 라이브를 규모에 따라서 미리 생각해본다.
규모가 작으면 contex / 리듀스
대규모, 리코일 vs 리덕스
웬만한 큰 규모가 아니면 ?
컨텍스트와 리듀서를 통해서도 충분히 가능하다.
디버깅 이론
디버깅을 걸때 자주 거는게 useEffect
useEffect에서 console.log를 찍을것
대괄호로 한 번만 실행되니까 useEffect로 통하여
한 번만 console.log가 실행된다.
setter로 통해서 리랜더링이 되는데,
일반변수는 세터가 없어서 리렌더링이 될 수 가 없다.
상위 컴포넌트에서 하위로 옮겨주었을때,
Prop 자체를 바꿀 수 있을가? 없다.
파라미터 최초의 값이기 때문에 값을 바꿀 수 없다.
디버깅 원리
- 리랜더링의 타이밍/ 대상이 누구인지?
그에 따른 계산 오류.- 이벤트를 다 주석하고 찍어보기
- 뷰가 나오게 마운팅 시켜놓고 확인해보기
특정 변수라던지, 이벤트 호출이 명확하지 않았을때
웹페이지는 실시간이란 개념이 없다.
사실상 리랜더링.
결론,
처음에 프로젝트가 있다 과정하면
1 라우팅을 어떻게 할건지 우선 설계
2 컴포지팅(view)
3 컴포넌트들이 구분이 됨.
4 상태관리 라이브러리 적용할 거 생각하면서 쓰기.
5 마운팅 되고 랜더링 된 후 호출.
🏆 hook에서 useEffect 중요하다!!!!!!!!
