2021-06 개발 아티클 읽기

❤Recoil레시피 0604

리코일을 적용했던 미션이 끝난 후 제대로 다시 읽게된 리코일에 대해 정리한 글이다. 우선 한글로되어있어 처음 접하는 사람에게는 큰 도움이 될 글이다.

• 이번에 리코일을 적용해보면서 Atom의 default값을 줄때 단순한 형태 숫자, 빈 배열, 문자 형태로 주었는데, 다음엔 default값을 key:value형태로 사용해서 무분별하게 늘어난 atom을 정리해야겠다.

• selector가 어렵게 느껴졌다. 그래서 미션 종료직전까지 셀렉터 사용을 미루다가 살짝 적용해보게 됬는데 사실 필수적인 기능은 아니었다. 개개인이 느끼기에 따라 다르겠지만 있어도, 없어도 된다. atom에서 관리하는 상태들을 변경하고 싶어지면 atom값을 불러와서 다른 외부함수에서 조작할수도 있으니까, 그런데 상태를 관리입장에서 selector로 정의해둔 atom과 함께 데이터를 가공 및 관리하는것이 더 효율적이라는 생각이 들었다. 무었보다도 상태파일을 분리하게 되니 컴포넌트 파일이 깔끔해졌다. 또한 외부함수로 사용할 때엔 함수에 필요한 값들을 인자로 전달해주어야 했는데 셀렉터를 사용하니 이미 그 안에 필요한 값이 정의되어있어 코드가 더욱 간단해지는 이점을 느낄 수 있었다.

• atom의 기본값 : 정적, 프로미스, 리코일 벨류 사용가능
  atom의 값으로 프로미스와 다른 리코일 밸류를 사용할 수 있다는게 신기!

• 생각보다 리코일 기능이 엄청 많았다. 다음 미션때에는 selector를 통해 데이터를 요청하고 suspense를 꼭 적용해봐야겠다.

+ When to useMemo and useCallback 0605

최적화를 위해 useMemo, callback을 남발하는 것은 더 큰 비용을 양산함. 꼭 최적화가 필요한지 측정을 먼저한 후 잘 적용해야 한다.

• 블로그 결론부 > useCallback,useMemo의 비용은 코드가 복잡해질 수 있고 dependecies array같은데서 실수를 할수 있다는 것, 그리고 잠재적으로 내재되어있는 hook들을 사용하고 dependencies 그리고 memorized 된 값들이 가비지 컬렉티드 되는것으로 부터 방지함으로써(메모리를 낭비히므로) 퍼포먼스를 안좋게 만들 수 있다. 측정을 먼저하는것이 최우선시 되어야 합니다.

+ 이벤트 버블링, 이벤트 캡처 그리고 이벤트 위임까지 0606

기본적인 개념을 다루고 있는 글이다. 그래도 한번은 정확하게 정리하고 넘어가고싶었다. 이벤트 위임은 대충 그림은 그려졌는데 내용을 명확히 알지 못했던 것 같아 좋은 기회였다.

특히 이번 에어비앤비 미션에서 하나의 검색바에서 각 섹션들에 클릭 이벤트를 주어야 할 일이 있었는데, 현재는 작은 섹션마다 클릭이벤트가 걸려있다면, 반대로 검색바 전체 영역에서 이벤트 위임으로 이벤트를 전달했다면 코드중복을 피하고 (영향이 크지않지만)메모리누수가 좀 줄었겟지?

• 이벤트 위임의 장점
  • 요소마다 이벤트 위임을 할당하지않고 요소들의 공통 조상요소에 한번만 걸어도 여러 요소들을 한꺼번에 컨트롤할 수 있다. 때문에 초기화가 쉽고 메모리가 절약된다.
  • 이벤트가 걸려있던 요소를 수정하거나 삭제할때에도 이벤트 핸들러를 추가하거나 제거할 필요가 없어 코드의 수정이 용이하다.
    ✨새로추가된노드에 이벤트가 걸리지 않는 문제
  • event.target을 통해 실제 이벤트 발생지점을 파악할 수 있다. (이벤트가 걸려있지 않은 부분에까지 응답을 해야하지만 cpu입장에서 큰 부담이 되지않기 때문에 무시할수있는 수준의 아쉬움이다.)
• 리액트의 경우 각 컴포넌트마다 이벤트를 거는 것 처럼 보이지만 크게는 root에 이벤트가 걸리고 하위컴포넌트로 위임, 전달되는 방식이다. 실제로 리액트에서 우리가 하는 것은 이벤트 핸들러 콜백함수만 설정해주는 것이다.
  ✨리액트 에서의 이벤트 위임

+ 우아한개발자인터뷰 0607

이 인터뷰는 경력자 입장에서 실무를 하며 경혐했던일, 문제 상황과 해결한 과정을 엿볼 수 있는데 나중에 이력서 쓰는데 참고가 될것 같다. 그리고 나도 작은 소스들이라도 매일 기록하자 TIL시작했으니께!

Merge이해하기

+ 4 folder structures to organize your React & React Native project 0611

이슈트래커 미션 초반 리팩토링을 하면서 폴더구조를 고민하게 되었다. 페이지폴더와 컴포넌트 폴더를 분리하여 관리하다가 컴포넌트와 페이지간의 연관성을 확인하기가 어려운듯하여 페이지 폴더내부에 직접적으로 해당되는 컴포넌트를 저장하는 식으로 변경하였다. 폴더링에 대한 고민을 위 기사를 통해 도움받았다.결론적으로는 상황에 따라 (풀스택인지, 디자인구성요소를 중요하게 여기는지 등) 다양한 폴더링이 장단점을 갖는데, 우선 내 입장에서 좋은 폴더링은 누가보아도 컴포넌트의 구성과 내용을 폴더구조를 통해 어렵지 않게 파악할 수 있는 것이라고 생각한다.

+ Index as a key is an anti-pattern 0612

• 키를 주어야 하는 이유: DOM 노드의 자식들을 재귀적으로 처리할 때, React는 기본적으로 동시에 두 리스트를 순회하고 차이점이 있으면 변경을 생성한다. 이 때 **어떤 항목을 변경, 추가, 삭제할지 key값을 기준으로 차이점을 식별하고 차이점만 렌더링에 새로 반영한다.
• 만약, 키값을 따로 지정하지 않으면 react에서는 자동으로 index를 key값으로 간주한다. 물론, key값을 설정하라는 경고 메시지는 꾸준히 발생한다.
• index key값의 문제점?
  - 리스트 컴포넌트들의 순서가 재배열되는 경우 인덱스가 달라져 state에 오류가 생길 수 있다.
• Key를 선택하는 가장 좋은 방법은 리스트의 다른 항목들 사이에서 해당 항목을 고유하게 식별할 수 있는 문자열을 사용하는 것 (보통 데이터의 고유 id를 key값으로 지정한다. 또한 전역이 아닌 형제요소에서만 구별가능한 key값이기만 하면된다., nanoid라는 id generator 라이브러리도 잇네.)

+ 마이리얼트립 웹사이트 성능 측정 및 최적화 Part 1. 리소스 로딩 0613

최적화를 수업때 접하긴했는데 이렇게 실무에 직접 적용한 사례를 보니 굉장히 재밌었다. 이를 규모있는 프로젝트를 만들고 싶다는 욕구도 생겼다. (에어비앤비 클론은 서버가 아쉽게도 닫혔음...ㅠ) 그리고 cra가 아닌 정말 필요한 기능들만 가볍게 갖춘 웹팩설정을 공부해야겠다고 생각하게 됬다. 기존까지는 웹팩 어휴... 이랬다면 이젠 목적(가볍고 최적화된 앱을 만들기)이 생겼기 때문에 부담스럽지 않게되었다.

+ 마이리얼트립 웹사이트 성능 측정 및 최적화 Part 2. 렌더링