Growth Log : by dpwls

Appearance

0721 ​

내일은 테스팅 라이브러리 봐야지..
밤엔 이제 다시 알고리즘 공부 시작해야지..

clone coding ​

observer hook ​

  • 관련 PR: https://github.com/dpwls02142/shopping-app/pull/49
  • observer란?
  • js에선 new IntersectionObserver 키워드를 활용해 observer 객체를 생성할 수 있다.
  • 해당 api를 사용하게 된 배경은 다음과 같다.
    • Product Detail View에서 사용자가 보고 있는 영역이 review 섹션이면 review 탭을, description 섹션이면 description 탭을 활성화시키기 위함이다.
    • 그래서 useProductTab이라는 커스텀 훅을 제작해 각 섹션이 뷰포트 내에서 일정 비율 이상 보일 때 해당 탭을 active 상태로 전환하도록 했다.
    • 이때 Intersection Observer의 threshold를 0.3으로 설정해, 요소가 화면에 30% 이상 노출될 경우 콜백이 호출되도록 했다
    • 처음에는 forEach로 각 entry의 상태를 순회하며 처리했지만, 이 방식은 여러 요소가 동시에 threshold를 만족할 경우 어떤 탭을 active로 설정할지 모호해지는 문제가 있었다.
    • 이를 해결하기 위해 reduce를 사용해 intersectionRatio가 가장 높은 entry 하나만을 선택하고, 그에 해당하는 탭만 setActiveTab으로 업데이트되도록 수정했다. 이 방식은 동시에 여러 섹션이 보일 때도 가장 적절한 섹션을 기준으로 탭을 설정할 수 있도록 해준다.
  • observer를 사용하지 않고 다른 방법은 없었는가?
    • Element.getBoundingClientRect() 를 활용해 유사한 기능을 구현할 수는 있지만, 이 방식은 성능상 불리하며 스로틀링 등 추가 처리가 필요하기 때문에 Intersection Observer를 사용하는 것이 더 효율적이고 유지보수 측면에서도 유리하다.
      • 왜 getBoundingClientRect는 성능상 불리한가?
      • 사용자의 매 스크롤에 반응하여 직접 연산을 해야하므로 성능이 저하되기 쉬워 스트롤링을 적용해야 되기 때문이다.
  • 그래서 이럴거면 intersetcion observer를 사용하는게 좋다.
    • 왜냐면 threshold 지점을 지나갈 때마다 콜백 함수가 호출되기 때문이다.

image의 key를 index로 처리했을 때 문제점 ​

  • react에서 key는 리렌더링 시 컴포넌트의 identity를 보존하기 위한 역할을 한다.
  • 근데 index를 key로 쓰면 리스트가 변경 될 때 예상치 못한 오류가 발생할 수 있다.
    • 구체적으로 어떤 오류?
      • 현재 description image의 배열이 [img1, img2, img3]과 같은데,
      • 판매자가 img1과 img2 사이에 new라는 새로운 image를 추가했다고 가정하자. 그럼 배열이 [img1, new, img2, img3] 으로 바뀔거고
      • 이러면 key값이 0 = img1, 1 = new, 2 = img2, 3= img3이 될거다.
      • 근데 이 때 key를 index로 설정한다면 react는 이전에 쓰던 DOM을 그대로 key로 재사용한다.
      • 즉 ui는 정상처럼 보여도 react 입장에선 image 컴포넌트에 전달 된 effect가 있다면 잘못된 상태로 이어질 수 있다.
  • 결론: image의 key 값은 url을 쓰자

CS ​

IPC (Inter Process Communication) ​

  • ipc란?
    • 프로세스들간의 커뮤니케이션(의사소통)
  • ipc의 종류
    • pipe
      • 부모 자식 간 단방향 통신
      • 마치 수도 파이프처럼 한쪽에서 물(데이터)를 넣으면 다른쪽에서 받는 구조
      • 즉 한쪽은 쓰고 한쪽은 읽기만함.
    • named pipe (FIFO)
      • 다른 프로세스와 단방향 통신
      • pipe와 비슷하지만 이름을 가진 파일 형태로 통신을 함. 그래서 named pipe
      • 파이프를 두 개 만들면 양방향 통신이 가능함
    • message queue
      • 다른 프로세스와 단방향 통신
      • 커널이 관리하는 메시지를 저장하는 큐에 데이터를 삽입하고 꺼내는 방식.
      • 프로세스 간 비동기 통신이 가능함.
    • shared memory
      • 다른 프로세스와 양방향 통신
      • 둘 이상의 프로세스가 동일한 메모리 영역에 직접 접근
    • memory map
      • 다른 프로세스와 양방향 통신
      • 파일을 메모리에 매핑하여 공유
    • socket
      • 다른 프로세스와 양방향 통신
      • 다른 컴퓨터 사이에서도 통신이 가능

동기화 ​

  • 세마포어
    • 스레드/프로세스의 진입을 제어하는 정수형 값
    • 세마포어 초기값이 3이면 3개까지 동시 접근이 가능 (카운팅 세마포어)
    • 이진 세마포어는 뮤텍스와 비슷하게 동작함.
    • 그래서 공유 자원이 여러개일때 유용.
  • 뮤텍스
    • 동시에 단 하나의 스레드/프로세스만 진입을 허용함
    • 한 번에 하나만 잠글 수 있고 락을 획득한 스레드/프로세스만 락을 해제할 수 있음.
    • 한마디로 자기거는 자기만 풀 수 있다는거임.