디자인과 기획이 전체적으로 바뀌면서 2.0버전 업데이트를 기획하게 되었습니다.
디자인과 기획적인 면에서 더 섬세하고 많은 기능들이 요구되었기에, 이에 맞춰 프론트엔드 단에서는 웹뷰 사용을 생각하게 되었습니다.
또한 프론트엔드 개발 측면에서도 빠르게보다는 효율적으로 목표가 바뀌었기에 웹뷰를 생각하게 되었고, 사이드 프로젝트인만큼 많은 것들을 시도해보고 싶었습니다.
웹뷰로 바꾸려는 가장 큰 이유
1.0 버전에서도 카카오 맵 api같은 경우엔 웹뷰를 사용하여 구현했었는데, ReactNative 내에서의 웹뷰이다보니 값을 넘길 때나 가져올 때 불편한 점이 있었습니다.
특히나 RN -> Web의 경우, script 코드들을 삽입하는 방식을 사용했었는데 iOS에서는 제대로 작동되지 않는 문제점이 있었습니다.
웹뷰 렌더링이 끝난 이후 injectedScript 작업이 필요한데, iOS에서는 그 동작이 제대로 이루어지지 않아서 발생하던 문제였습니다.
웹뷰에서 사용하는 기술 스택 & 선정 이유
Next.js
: React.js를 이용해도 SSR 방식 등 Next.js 주요 특징들은 구현할 수 있습니다.
하지만 Next.js 레퍼런스를 읽어보며 사용해본 결과 React.js보다 많은 기능들을 사용할 수 있었기에 선택했습니다.
기본적으로 ssr 방식을 갖고 있고, 폴더 이름에 따라 자동으로 라우팅이 되는 등 작업을 훨씬 빠르게 할 수 있었습니다.
Typescript
: React, ReactNative 쪽에서도 Javascript에서 Typescript를 더 지원하는 방향으로 가고 있기에 선택했습니다.
Javascript를 이용한다면 더 빠르게 완성(신경써야 할 문법적인 요소가 적어지기 때문)할 수 있겠지만, Typescript를 사용하는 편이 예상치 못한 오류에 대비할 수 있어 선택하였습니다.
CSS-in-JS(styled-components)
: 컴포넌트화에 용이하고 값을 넘겨 애니메이션 효과를 주는데 편리함이 있어 사용하려 합니다.
특히 컴포넌트화를 잘 해두게 되면 나중에 비슷한 기능이 있을때 가져와 사용하면 됨으로 굉장히 편리하기에 선택하였습니다.
redux-toolkit
: 1.0 버전에서는 recoil을 사용했었습니다. 하지만 새로운 것을 시도해보고, 함께 일하는 개발자 분께서 액션 함수 정의하고 사용하는데 편리하다는 의견을 반영해 사용하려 합니다.
react-query
: 서버의 값을 클라이언트로 가져오는 것을 더 편리하게 하기 위해 사용해보려 합니다.
특히 무한 스크롤 들어가는 곳이 많아 서버에서 받아온 값을 관리(캐싱, 값 업데이트)해야하는 경우가 많은데, 이를 편리하게 다루기 위해 선택했습니다.
(+ emotion)
: 퍼블리싱을 도와주는 라이브러리라 사용해보려 합니다.
