2023 07 06
2023-07-06¶
React StrictMode¶
참고: https://www.youtube.com/watch?v=MXSuOR2yRvQ 참고: https://velog.io/@jay/you-might-need-useEffect-diet
- 컴포넌트 마운트 -> 언마운트 -> 마운트
- Connecting -> Disconnected -> Connecting 순서
- API 한번만 호출하려면 첫 마운트에만 가져오도록 useRef() boolean 으로 flag 걸어두자
React 생명주기¶
참고: https://www.zerocho.com/category/React/post/579b5ec26958781500ed9955 참고: https://www.zerocho.com/category/React/post/5f9a6ef507be1d0004347305
- 리액트 생명주기
- 컴포넌트가 실행/업데이트/제거시 이런 이벤트들이 발생
- 근데 클래스기반 컴포넌트랑 함수형 기반 컴포넌트랑 생명주기가 조금 다르다네?
- 클래스 기반 컴포넌트 생명주기
- [Mount]
- 컴포넌트가 처음 실행될 때
- 컴포넌트 시작시 context, defaultProps, state 저장
- componentWillMount 메서드 호출
- render를 통해 컴포넌트를 DOM에 부착
- componentDidMount 메서드 호출
- 여기서 DOM에 접근 가능
- Ajax 요청, setTimeout, setInterval 등이 가능
- [Props Update]
- props가 업데이트될 때
- componentWillReceiveProps 메서드 호출
- shouldComponentUpdate 메서드 호출
- componentWillUpdate 메서드 호출
- 업데이트 완료후 render 완료
- componentDidUpdate 호출
- 꼭 필요한 업데이트 아니면 쳐내서 성능 최적화
- [State Update]
- setState 호출을 통해 state가 업데이트 됨
- props update와 과정이 같지만, componentWillReceiveProps 메서드 호출 안됨
- 동일하게 shouldComponentUpdate -> componentWillUpdate -> render -> componentDidUpdate
- [Unmount]
- 컴포넌트 제거
- componentWillUnmount
-
함수형 기반 생명주기 - UseEffect 쓰자!
- 클래스는 커포넌트에 생명주기가 맞춰져있었어
- 리액트 17 부터는 componentWillMount, componentWillUpdate, componentWillReceiveProps 라이프사이클 없어짐!
- 함수형은 특정 데이터에 대해서 라이프사이클이 진행된다!
- 데이터는 여러개이기에, useEffect는 데이터의 갯수에 따라 여러번 사용하게 됨
- [첫 렌더링 시 실행, 바뀔때마다 실행]
- componentDidMount + componentDidUpdate
- [componentWillUnmount 까지 포함하기 - 마운트 끝날때 이거 호출해주세요]
- [빈배열을 넣어 마운트 될 때, 언마운트 될 때 한번씩!]
- [리렌더링 될 때마다 한번씩! - 빈배열도 넣지마~]
브라우저 캐시¶
참고: https://toss.tech/article/smart-web-service-cache 참고: https://sarc.io/index.php/miscellaneous/1565-browser-cache 참고: https://hahahoho5915.tistory.com/33
- 개요
- 브라우저가 웹 서버의 일부 컨텐츠를 요청
- 컨텐츠가 브라우저 캐시에 없으면 웹 서버에서 직접 검색
- 컨텐츠가 이전에 캐시되었다면 브라우저는 서버를 우회하여 캐시에서 직접 컨텐츠 로드
- 브라우저 캐싱은 특정 HTTP 헤더를 사용해 웹 개발자와 관리자가 활용할 수 있음
- 자원을 언제 캐시할 지, 얼마나 오래 캐시할지 웹 브라우저에 지시
- 웹 프록시, 오래된 브라우저, 충돌 캐싱 정책 등을 고려해야 함
- Cache-Control
- No-cache
- 브라우저가 즉시 캐시를 참조하지 않고, 서버에 대해 컨텐츠 유효성을 검사하도록 지시
- Fresh의 경우 캐시에서 제공
- No-store
- 브라우저가 컨텐츠를 캐시하지 않도록 지시
- 민감한 데이터 or 자주 변경되는 데이터를 다룰 때 주로 사용됨
- Public
- 컨텐츠를 공개로 표시, 브라우저 및 프록시 등 중개자가 캐시할 수 있음
- Private
- 컨텐츠 표시하는데 사용.
- 중간 프록시 등이 아닌 브라우저에서만 캐시 가능
- Max-age
- 클라이언트가 클라이언트 유효성을 다시 확인해야 브라우저 캐시에 콘텐츠를 남겨 둘 수 있는 최대 시간
- Expires와 달리 컨텐츠가 캐시된 시간의 상대값을 초 단위로 정의
- 만료 날짜가 아니라는군...
- No-cache
- 웹 캐시의 종류
- 브라우저 캐시
- 브라우저, HTTP 요청을 하는 ClientApplication 내부 디스크에 캐시
- Cache된 Resource를 공유하지 않는 한 개인에 한정된 Cache
- 브라우저의 BackBtn, 이미 방문한 페이지 재 방문의 경우 극대화
- 프록시 캐시
- Client나 Server가 아닌 네트워크 상에서 동작
- 큰 회사나 IPS의 방화벽에 설치되며 대기 시간 & 트래픽 감소, 접근 정책 & 제한 우회, 사용률 기록 등
- 한정된 수의 클라이언트를 위해 무한대의 웹서버 컨텐츠 캐시
- 약간 CDN 같기도 하네
- 게이트웨이 캐시
- 서버 앞단에 설치되어 효율적인 분배를 통한 가용성/신뢰성/성능 향상
- Encryption, SSL 등
- 무한대의 클라이언트 상대하는 하나의 웹서버 컨텐츠
- 브라우저 캐시