FE

1. React-Slick, Slick-carousel

1. 필요성:

   • 이번 프로젝트에 한 두개의 캐러셀을 만드는것이 아닌 메인페이지, 마이페이지 등 다양하게 적용을 해야 하는데 리액트 만으로 구현할 시 하단에 무한 캐러셀 또는 dot, arrow, 그리고 컨텐츠를 계속 돌릴것이냐 왼쪽 또는 오른쪽 끝까지 돌릴시 막힐 것이냐의 유무 등 고려해야 할 것이 많으며 단시간에 구현하며 리액트의 불필요한 코드를 줄이고 state관리를 하기 편한 라이브러리를 찾게 되었습니다.

   • 입력 받을 데이터 예시

     <Main>
     유저닉네임 / 유저프로필사진 url
     유저가 정한 음료양 / 유저가 만든 레시피 비율
     유저가 정한 색깔 / 유저가 좋아요를 누른갯수
     <Mypage>
     유저닉네임 / 유저프로필사진 url
     유저가 정한 음료양 / 유저가 만든 레시피 비율
     유저가 정한 색깔 / 해당 유저가 작성한 레시피에 대한 유무 / 해당 유저가 특정 레시피에 대해 좋아요 눌렀는지에 대한 유무
     

2. 고민대상:

   • react-slick + slick-carousel

   • nuka-carousel

     • 선택하지 않은 이유

       • 해당 라이브러리가 출시한지 얼마 되지 않아 참고할 자료나 피드백이 많이 없었습니다.
       • v4버전에서 오류가 많이 있었던걸 찾았으며 v5버전은 개선되며 반응형 옵션도 넣었다고 되어 있지만 어떤 오류가 생길지 모른다는 생각에 짧은 프로젝트 기간을 고려했을때 더 안전한 라이브러리를 고려할 수 밖에 없었습니다.
       • 참고 source:

       nuka-carousel

   • react-responsive-carousel

     • 선택하지 않은 이유

       • Typescript에 더 특화된 라이브러리이며 반응형에 더 특화된 라이브러리라 다양한 상황에서 원할하게 돌아가야 하는 저의 프로젝트의 취지와는 조금 거리가 멀었습니다.
       • 참고 source:

       react-slick vs react-responsive-carousel | LibHunt

3. 선택하게 된 이유:

   • react-slick + slick-carousel
     • 라이브러리의 장점
       • setting과 css수정의 자유도가 높아 캐러셀을 다양한 형태로 여러개 만들어야 하는 우리의 프로젝트의 방향성에 잘 맞아 떨어지며 커스텀한 코드를 다른 캐러셀에 입히는게 쉽다는 장점이 있습니다.(dots, arrows, 속도 속성 하나하나 모두 커스텀을 할 수 있습니다)
       • 해당 프로젝트가 반응형 디자인과 PWA를 염두해 두고 있기 때문에 반응형 옵션이 들어가 있는 라이브러리가 필요했는데 해당 라이브러리는 그에 대한 조건을 갖추었습니다.

4. 후기:

   • 해당 라이브러리의 자유도가 있어 원하는 페이지를 어느정도의 규격과 패턴으로 보여주는 상황에 있어서는 합리적으로 구현을 할 수 있었으나 css작업을 하면서 node modules 자체 내에 속성 값이 들어가 있어 정확히 로직을 짜는 부분에 있어서 조금의 어려움을 느꼈습니다.
   • 구현시간을 대폭 줄일 수 있었으며 렌더링 등 기능 개선또한 가능하다고 판단이 되어 기능개선을 계속 할 예정입니다.

2. React-Intersection-Observer

1. 필요성:

   • 우선 무한스크롤 기능은 최대한 기능적으로 중요하며 유저가 스크롤을 내릴 시 불편함을 안 겪는 부분이 중요하다고 생각하였습니다. 우선 브라우저의 기본 onScroll 이벤트로 구현을 생각했는데 페이지 끝까지 유저가 스크롤을 했을때, 브라우저의 기본 스크롤 이벤트를 이용해서 그 시점을 감지해 다음 이미지를 받아오는 요청을 할 시 스크롤이 페이지 끝에 닿았을때마다 page값을 하나씩 증가시켜 다음 fetch 요청을 보내게 되는데 스크롤을 다 감시하고 있어야 해서 페이지를 탐색하는 동안 해당함수가 매번 호출되는 문제를 겪어야 했다. 이를 해결하기 위해 다양한 라이브러리를 찾게 되었습니다.
   • 입력 받을 데이터 예시

   유저닉네임 / 유저프로필사진 url
   유저가 정한 음료양 / 유저가 만든 레시피 비율
   유저가 정한 색깔 / 좋아요의 갯수
   

2. 고민대상:

   • lodash라이브러리의 throttle 사용
     • 선택하지 않은 이유
       • 리소소를 줄이며 스크롤 이벤트가 트리거 되는 양을 어느 정도 줄일 수 있지만 주기를 너무 짧게 하면 throttle을 적용하는 효과가 적으며 throttle 주기를 크게 한다면 유저가 페이지 끝을 빠른시간안에 도달할 시 유저가 그 시간만큼 기다려야 fetch 함수가 실행된다는 치명적인 단점이 있다.
       • throttle의 적절한 주기를 정할 수 있다고 하여도 스크롤이 움직일때마다 이벤트가 발생하는 핵심문제를 해결하지 못한다.
   • Intersection Observer API 사용
     • 선택하지 않은 이유
       • 라이브러리를 따로 다운로드 받지 않아도 되며 스크롤 이벤트를 핸들링하지 않아도 되며 비동기적으로 실행이 되기에 메인스레드에 영향을 주지 않고 scroll 같은 이벤트 기반의 요소 관찰에 발생하는 렌더링 성능이나 이벤트 연속호출 같은 문제 없이 사용이 가능하나 observer라는 인스턴스를 생성하며 코드를 길게 만들며 설정값이 복잡해집니다.
       • observer로 무한스크롤을 구현하면 스크롤을 계속 밑으로 내려서 데이터가 100개, 1000개 등 많이 쌓이게 되면 브라우저 dom은 100개 또는 1000개 이상의 데이터가 추가되어 브라우저는 버벅이며 사용자의 UX가 나빠지는 성능 이슈를 겪게 됩니다.
   • react-intersection-observer

3. 선택하게 된 이유:

   • react-intersection-observer
     • 라이브러리의 장점
       • 기존의 throttle방식 또는 intersection observer api에서 observer역할을 했던 기능들이 useInView라는 기능으로 유저의 스크롤이 바닥을 닿을시 true/false 값으로 감지하여 페이지수를 늘리는 로직으로 코드도 간결해지며 intersection observer api의 기능을 조금 더 편의성을 제공하면서 성능개선을 도와줍니다.
       • threshold와 같은 속성값으로 타겟요소가 뷰포트의 몇 퍼센트만큼 들어왔을 때 fetch요청을 하여 붙이는 방식을 적용할 수 있어 개발하는데 있어 원하는만큼의 순간 무한스크롤을 구현할 수 있습니다.

4. 후기:

   • 많은 리소스가 있어 구현하는데 어려움은 겪지 않았으나 실제 스크롤을 아주 많이 내려서 많은 이미지들이 DOM에 렌더링될시의 성능저하 문제가 개선이 되어있는지는 지속한 관찰이 필요합니다. 성능저하를 확인한다면 react-virtualized 또는 react-window라는 라이브러리를 사용하여 실제 보이는 컴포넌트만 DOM에 렌더링하여 문제를 해결할 수도 있기에 성능 개선의 여지를 보고 있습니다.

3. react-jwt

1. 필요성:
   • 이번 프로젝트는 트래픽에 대한 부담을 줄이며 암호화와 복호화 방식을 통해 정보를 안전하게 주고받는 JWT의 refreshtoken과 accesstoken의 활용을 극대화하기 위해 JWT토큰을 이용해야 한다는 결론을 내렸습니다. 우선 세션방식과 다르게 별도의 인증 저장소가 필요 없어서 서버와의 커뮤니케이션을 최소한으로 할 수 있으며 트래픽에 대한 부담이 적고 독립적인 느낌의 JWT를 활용할 수 있다는 장점이 있습니다.
2. 고민 대상:
   • react-jwt
   • jwt-decode:
     • 선택하지 않은 이유:
       • jwt안에 있는 정보를 꺼내오는 용도로만 사용하기 위해서 가벼운 용도로 사용하기는 좋으나 직접적으로 jwt를 사용하기 위해서는 다양한 용도로 사용할 수 있는 라이브러리가 더 적합했습니다.
3. 선택하게 된 이유:
   • react-jwt
     • {decodedToken, isExpired} 기능으로 언제 token이 만료하는지 그리고 따로 특별한 라이브러리를 다운로드 하지 않아도 token안에 정보를 decode할 수 있는 decodeToken 속성이 담겨 있습니다.
     • refreshtoken method를 사용할 수 있으며 reEvaluateToken이라는 속성으로 useJWT의 상태를 새로 업데이트 할 수 있습니다.
4. 후기:

4. React hook form

1. 필요성:

   • 이번 프로젝트는 form으로 받아야하는 데이터의 종류가 다양하고, 갯수가 많습니다. 코드가 길어지고, props drilling을 하는 경우를 막기 위해서, 랜더링 관리 또는 validation 처리 및 에러 핸들링 등을 관리할 라이브러리를 찾게 되었습니다.

   • 입력 받을 데이터 예시

     유저 이메일 / 유저 비밀번호 / 유저 닉네임 / 유저 프로필 사진 url /
     유저가 정한 음료 양 / 음료 얼음 타입 / 유저가 만든 레시피 비율 / 
     유저가 정한 재료의 갯수 / 레시피 재료 색상 / 댓글 내용 / 댓글 사진 url ...
     

2. 고민 대상

   • 전역 상태 관리 State management
     • redux-toolkit
   • React-Hook-form
     • 랜더링 문제를 해결하고, validation 처리 및 에러 핸들링을 효율적으로 하기 위해 해당 라이브러리를 찾게 되었습니다.
     • 라이브러리의 장점

       1. react-hook-form은 비제어 컴포넌트 방식으로 구현되어 있습니다. 데이터를 확인하며 랜더링을 일으키거나 일으키지 않을 수 있고, 하위 컴포넌트에서 props drilling없이 form의 상태를 확인할 수 있습니다.

       2. 각 데이터 state가 동기화되며 한 곳에서 관리합니다.

       3. useFromState hook으로부터 받은 errors객체를 통해 각 섹션의 에러를 확인하고, 상태관리를 적용할 수 있습니다.

          errors.recipe?.message
          

       4. post 요청을 위한 데이터 관리

          • handleSumit함수를 통해 사용자가 에러가 없는 form을 제출했음을 확인할 수 있습니다.(유효성 검사)
          • validation 처리 및 에러 핸들링을 적은 코드로 수행 가능
     • 단점:
       • 외부 라이브러리에 의존하게 됨
       • 해당 라이브러리를 잘 다루는 팀원이 없기 때문에 전체적인 학습 필요

3. 선택하게 된 이유

4. 후기

5. Styled-Component

1. 필요성
2. 고민
3. 선택 이유