0811
React
왜 useMemo는 비호인가
- 비호라는 용어가 좀 그런가 암튼 useMemo를 남용하는게 안 좋다는데 왜일까?
- 값을 다시 계산하는 것이 memoization보다 더 빠를 수 있기 때문이다.
- 즉 성능 최적화를 위한 조기 사용이 오히려 성능을 해칠 수도있기 때문이다.
- 이런 경우가 언제 있는가?
- 재계산보다 캐싱 관리가 더 비쌀 때
- useMemo는 값을 재사용하기 위해 내부에 저장소를 유지하고 의존성 비교를 매 렌더링마다 진행한다. 내가 a+b라는 연산만 하고 있는데 이 값을 유지하기 위해 메모리도 쓰고 cpu도 쓰는게 좋을까? 아님 걍 cpu 연산만 처리하도록 하는게 좋을까? 닥후자 아닐까? 그래서 아무리 referential stability가 필요한 상황이더라도 연산이 가벼우면 useMemo를 안 쓰는게 좋다고 하는 거다.
- 재계산보다 캐싱 관리가 더 비쌀 때
- 그럼 useMemo는 언제 진짜로 사용하는게 좋을까?
- referential stability가 필요하면서 연산이 무거운 경우
- referential stability가 뭔데?
- 같은 의미의 값을 계속 같은 reference(주소)로 유지하는 것.
- 즉 매 렌더링마다 객체나 함수의 메모리 주소가 바뀌지 않게 하는 것.
- useEffect의 의존성 배열에 객체나 배열이 들어갈 때 useMemo를 사용하지 않으면 매 렌더마다 새 객체가 생성되어 useEffect가 매번 생성됨.
- referential stability가 뭔데?
- referential stability가 필요하면서 연산이 무거운 경우
- 결론이 뭐임??
- useMemo를 사용할 시엔 ram과 cpu 사용량이 모두 증가하는 대신 재사용시 cpu 연산 비용이 줄어든다.
- 반면 useMemo를 사용하지 않으면 cpu 사용량만 증가한다.
- 그럼 그냥 안 쓰는게 좋은거 아닌가요? 라고 생각이 들긴 하는데.....
- 웹앱 특성상 메모리 보다 cpu가 반응 속도에 영향을 주기에 ux에 더 직결되는 요소이다 고로 연산이 무겁다면 useMemo로 캐싱을 하고 가볍다면 그냥 useEffect쓰는게 낫다. 근데 캐시값이 너무 크다면 ram이 압박될테니까 이 땐 또....... 음 어렵다.
- 아니 근데 대체 연산이 무겁다는게 뭐지? 너무 추상적인거 아닌가? 하고 지피티한테 물어봤는데
TIP
- gpt의 말씀
- 렌더 사이클에서 한 연산이 1~2ms 이상 걸린다면 꽤 무거운 연산이라고 볼 수 있다고 한다.
- 왜냐면 우리가 사용하는 모니터는 보통 60Hz 주사율을 갖고있다.
- 즉 1초에 화면을 60번 새로 그린다는 말이다.
- 1s(1000ms)를 60으로 나눈 값은 약 16.7이기에,
- 한 프레임을 그리는데 모든 작업이 16.7ms 안에 끝나야 화면이 자연스럽게 바뀐다.
연산이 몇 초 걸리는지 아는 방법은 react profiler를 사용하면 된다.
참고 자료
DB
정규화
- 정규화란 관계형 데이터베이스 설계에서 데이터 중복을 줄이고 데이터 무결성을 개선하기 위해 데이터를 normal form에 맞도록 구조화하는 프로세스를 뜻한다.
- 관계형 데이터베이스?
- 데이터가 열(속성)과 행(값)을 이루는 하나 이상의 테이블로 정리되며 primary key가 있는 데이터베이스. 그래서 primary key를 다른 테이블에 forgien key로 연결하여 사용할 수 있는 테이블 형태. 비관계형 데이터베이스는 이미지나 비디오 같은 반정형, 비정형 콘텐츠를 저장하는데 유용함.
- 데이터 무결성?
- 데이터가 검색, 처리, 저장되는 모든 과정에서 데이터가 변경되거나 손상되지 않도록 보장하는 특성
- 관계형 데이터베이스?
- 1NF
- 모든 도메인은 원자값을 가져야 한다.
- 2NF: 부분적 함수 종속 제거
- primary key가 두 개 이상(복합키)인 테이블에서 일부 키에만 종속되는 정보가 있으면 분리한다.
- 3NF: 이행적 함수 종속 제거
- 기본키가 아닌 컬럼은 기본키가 아닌 컬럼에 의존해선 안된다.
- BCNF: 결정자이면서 후보키가 아닌 것 제거
- 테이블 안에 어떤 정보가 다른 정보를 결정하는데 이 정보가 기본키가 아니면 분리해야된다.
- 4NF: 다치 종속 제거
- 한 테이블 안에 서로 관련 없는 여러 값들이 같이 있다면 제거해야 된다.
- 5NF: 조인 종속 만족
- 조인 종속성을 만족하도록 테이블을 분해한다.
- 조인 종속성?
- 하나의 큰 테이블이 있는데 이 테이블을 여러 개의 작은 테이블로 나눠도 나중에 다시 조인(합치기)하기만 하면 원래 테이블과 완전히 같은 정보를 얻을 수 있는 경우
- 조인 종속성을 만족하도록 테이블을 분해한다.
- 참고 자료
Ossca
- posting page 관련 코드를 마저 리팩토링 하는 시간을 가져보아요,,,,,
- 관련 PR: https://github.com/2025-contribution-nextjs-team5/ossca-team_nextjs/pull/154
template
- 기존에는 posting template이 있었는데 애초에 왜 template을 만들자고 했던거지?
- https://nextjs.org/docs/app/api-reference/file-conventions/template
- next.js에서 template의 용도는 layout과 반대로 리렌더링 되어야하는 요소일 때 사용하는건데
- 지금은 앞에 "posting"이라는 접두사를 붙이고 사용했으니까
- next.js에서 지원하는 template 역할을 안 하고 그냥 component 역할을 하는데 굳이 posting template이라고 컴포넌트명을 정해야될까?
- 그래서 component 하위로 위치를 수정하고 컴포넌트명은 PostingList로 변경함.
- 근데 그래서 template은 언제 쓰는거지?
- 라우트 변경할 때마다 무조건 리셋하고 싶을 때
data fetching
- github에서 데이터를 페칭해오는 부분이 각각 흩어져있어서 하나의 유틸로 관리하는게 유지보수에 쉽다고 생각함.
- 폴더 구조를 보니까 lib 폴더 안에 깃허브 유틸이 있길래 해당 파일에 뭉쳐놓았다
- 근데 보니까 상세 페이지에서 마크다운 콘텐츠를 갖고오는거랑 월별 포스팅 페이지에서 마크다운 콘텐츠를 갖고오는 로직이 다른데 함수명이 같아서 둘이 하나로 합치다가 계속 url 에러가 났다
- 그래서 detail page에서 쓰는용이랑 기본 posting page에서 쓰는용 두 개로 분할해줬다.
추상화
- 기존에 posting list에서 search 분기가 다 처리되고 있어서 컴포넌트의 책임이 명확하지 않음
- hook도 컴포넌트 안에서 관리되고 있음
- 도메인에 맞게 훅이랑 컴포넌트 분리스스슥
- 해당 과정에서 발생한 하이드레이션 문제는? 일단 지금은 use client 처리해놨는데 내일 다시 처리하겟삼