Skip to content

0811

React

왜 useMemo는 비호인가

  • 비호라는 용어가 좀 그런가 암튼 useMemo를 남용하는게 안 좋다는데 왜일까?
    • 값을 다시 계산하는 것이 memoization보다 더 빠를 수 있기 때문이다.
    • 성능 최적화를 위한 조기 사용이 오히려 성능을 해칠 수도있기 때문이다.
  • 이런 경우가 언제 있는가?
    • 재계산보다 캐싱 관리가 더 비쌀 때
      • useMemo는 값을 재사용하기 위해 내부에 저장소를 유지하고 의존성 비교를 매 렌더링마다 진행한다. 내가 a+b라는 연산만 하고 있는데 이 값을 유지하기 위해 메모리도 쓰고 cpu도 쓰는게 좋을까? 아님 걍 cpu 연산만 처리하도록 하는게 좋을까? 닥후자 아닐까? 그래서 아무리 referential stability가 필요한 상황이더라도 연산이 가벼우면 useMemo를 안 쓰는게 좋다고 하는 거다.
  • 그럼 useMemo는 언제 진짜로 사용하는게 좋을까?
    • referential stability가 필요하면서 연산이 무거운 경우
      • referential stability가 뭔데?
        • 같은 의미의 값을 계속 같은 reference(주소)로 유지하는 것.
        • 즉 매 렌더링마다 객체나 함수의 메모리 주소가 바뀌지 않게 하는 것.
        • useEffect의 의존성 배열에 객체나 배열이 들어갈 때 useMemo를 사용하지 않으면 매 렌더마다 새 객체가 생성되어 useEffect가 매번 생성됨.
  • 결론이 뭐임??
    • 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 안에 끝나야 화면이 자연스럽게 바뀐다.

DB

정규화

  • 정규화란 관계형 데이터베이스 설계에서 데이터 중복을 줄이고 데이터 무결성을 개선하기 위해 데이터를 normal form에 맞도록 구조화하는 프로세스를 뜻한다.
    • 관계형 데이터베이스?
      • 데이터가 열(속성)과 행(값)을 이루는 하나 이상의 테이블로 정리되며 primary key가 있는 데이터베이스. 그래서 primary key를 다른 테이블에 forgien key로 연결하여 사용할 수 있는 테이블 형태. 비관계형 데이터베이스는 이미지나 비디오 같은 반정형, 비정형 콘텐츠를 저장하는데 유용함.
    • 데이터 무결성?
      • 데이터가 검색, 처리, 저장되는 모든 과정에서 데이터가 변경되거나 손상되지 않도록 보장하는 특성
  • 1NF
    • 모든 도메인은 원자값을 가져야 한다.
  • 2NF: 부분적 함수 종속 제거
    • primary key가 두 개 이상(복합키)인 테이블에서 일부 키에만 종속되는 정보가 있으면 분리한다.
  • 3NF: 이행적 함수 종속 제거
    • 기본키가 아닌 컬럼은 기본키가 아닌 컬럼에 의존해선 안된다.
  • BCNF: 결정자이면서 후보키가 아닌 것 제거
    • 테이블 안에 어떤 정보가 다른 정보를 결정하는데 이 정보가 기본키가 아니면 분리해야된다.
  • 4NF: 다치 종속 제거
    • 한 테이블 안에 서로 관련 없는 여러 값들이 같이 있다면 제거해야 된다.
  • 5NF: 조인 종속 만족
    • 조인 종속성을 만족하도록 테이블을 분해한다.
      • 조인 종속성?
      • 하나의 큰 테이블이 있는데 이 테이블을 여러 개의 작은 테이블로 나눠도 나중에 다시 조인(합치기)하기만 하면 원래 테이블과 완전히 같은 정보를 얻을 수 있는 경우
  • 참고 자료

Ossca

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 처리해놨는데 내일 다시 처리하겟삼