분류 전체보기

이전 게시글에서 UI테스트를 하기 위해 Storybook을 도입했다. 각각의 프로젝트마다 각각의 컴포넌트 테스트를 해볼 수 있어서 좋을것이라 판단했다. 하지만 문제가 있었다. 배포가 너무 많다. 3개의 배포 3개의 레포에 대해서 chromatic을 통해 storybook을 각각 배포하다보니 두가지 문제가 발생했다. 테스트하기 힘들다. 배포 완료된 링크가 3개라 일일히 들어가서 테스트해봐야한다는 단점이 있다. 속도가 느리다. 위 사진처럼 순차적인 형태로 각각의 레포 storybook을 배포하다보니 2분씩, 총 7분가까이 걸리는 문제가 발생했다. 심지어 이 CI는 pull_request마다 돌아야하므로 더 자주, 더 많이 호출되어야한다. 또 우리 레포는 현재 4개의 프로젝트로 구성되어있고, 추후에 더 추가될..

이제 프로젝트는 앱 런칭을 앞두고 QA를 진행하고있다. 이렇게 QA를 진행하다보니 알게된 것은 생각보다 다양한 기기에서 테스트하다보니 UI가 깨지는게 많다는 점이었다. 그러나 의외로 UI 깨지는 것을 쉽게 해결하기가 쉽지않았다. 아래와 같은 이유들 때문이었다. 특정 사이즈에서만 깨진다. 아래와 같이 화면이 좁아지면 UI가 깨진 다던가... 문제가 있었다. 반응형 사이즈 테스트를 해볼 수가 없다. 서버 API호출을 줄여 운영 비용을 줄이기 위해 네이티브 DB를 사용하기로 결정했었다. 사용자가 쓴 글, 좋아요 누른 글 등을 앱 내부 DB에 저장하게 하고, 로그인시 서버와 1회 통신을 통해 동기화하는 형태로 서비스를 구성했다. 이렇게 앱 내부 DB를 사용하는 곳이 늘어나다보니 이제는 브라우저로 배포된 서비스 ..

무라카미 하루키의 소설을 처음 읽어보았다. 하루키의 문장들 처음 접한 하루키의 책은 달리기를 말할 때 내가 하고 싶은 이야기였다. 이 책은 에세이였어서 하루키의 문체를 제대로 경험하지 못했다는 걸 이번 책을 읽으면서 알게 됐다. 하루키의 문체는 정말... 뭐랄까... 모네의 그림같은 느낌이다. 나는 모네의 그림을 좋아한다. 분명 현실을 담았음에도 그 순간의 기억, 기분, 냄새까지 담겨 있는, 한순간의 추억을 담아내기때문이다. 하루키의 문장에서도 비슷한 느낌을 받을 수 있었다. 하늘은 더할 나위 없이 새파랗고 가늘게 흩뿌려진 구름은 마치 시험 삼아 페인트를 슬쩍 칠한 것 처럼 하늘 천장에 희뿌옇게 달라붙었다. 때로 머리에 깃털 장식 같은 것을 단 빨간 새가 눈앞을 가로질렀다. 푸른 하늘을 배경으로 날아가는..

이전 게시글들에서 React Webview와 ReactNative의 통신을 시켜보았고, 추가적인 데이터도 주입시켜보았다. 이때의 통신은 ReactNative->React 통신의 경우 onLoad시 React Webview에서 필요한 데이터를 한번에 주입시켜주는 형태 하나였고 React->ReactNative 통신이 대다수여서 불편함이 있지 않았었다. 하지만 프로젝트가 커지고, 서버 API호출을 줄이고자 내활동을 저장하는 부분에 대해 네이티브 기기의 DB를 사용하는 부분을 적용시켰고, 이에 따라 Webview가 열린 후에 데이터를 요청해야하는 부분이 점점 커져갔다. 기존의 방식 처음에는 native DB에 있는 하나의 데이터만이 필요하여 ReactNative의 WebView컴포넌트가 열린 후, onLoad..

이전 게시글에서 React Webview와 ReactNative의 통신을 시켜보았다. 이때의 방식은 WebView가 onLoad되었을때, React Webview에서 필요한 토큰을 주입하게 하는 형태였다. 하지만, 프로젝트가 커지고, 다양한 API요청이 많아짐에 따라 우리팀은 자연스럽게 비용문제가 발생할 수 있을거라는 걱정을 하게되었고, 이에 서버 API호출을 줄이고자 데이터를 받아오는 부분에서 네이티브 기기의 DB를 사용하기로 하였다. 문제상황 기기 DB에 저장된 데이터를 받아와서, 웹뷰에서 보여줘야했다. 이때의 DB테이블은 우리팀원이 이미 만들어 둔 상태였기에, 나는 이것을 조회해서 웹뷰에 넣어만 주면 됐다. 그런데 DB조회는 비동기적으로 일어난다. Promise를 resolve시켜야 실제 데이터를 ..

이번 년도에는 정보성 글, 자기계발서들에서 의도적으로 벗어나 소설을 읽어 보려 하고 있다. 그러던 중 서점에서 민음사코너를 보게 됐다. 쭉 훑다가 눈에 들어온 것이 무기여 잘있거라였다. 어니스트 헤밍웨이가 그렇게 대가로 유명하다는데 나는 그의 글을 한 번도 읽어본 적이 없었다는걸 알게 됐다. 과연 이 사람은 어떤 내용의 글을 어떻게 적었을지 궁금하여 선택하게 된 책이다. 인간은 죽는다. 그것이 무엇인지 몰랐어. 그것에 대해 배울 시간이 없었던 거야. 경기장에 던져 놓은 뒤 몇 가지 규칙을 알려 주고는 베이스를 벗어나는 순간 공을 던져 잡아 버리거든. 아이모처럼 아무 까닭 없이 죽이거나, 또는 리날디처럼 매독에 걸리게 하지. 하지만 결국에는 모두 죽이고 말지. 그것만은 분명해. 결국 살아남는다 해도 종국에..

이전 글에서 useInfinityQuery를 사용하여 무한 스크롤 피드를 구현해보았다. 하지만 두가지 문제가 존재했다. 새롭게 글을 작성/수정/삭제 하는경우 피드데이터는 어떻게 최신화 되어야 하는가? 세부 글보기에서 좋아요/댓글을 추가/삭제하는 경우 피드데이터는 어떻게 최신화 되어야 하는가? 이번에는 이 두 가지 문제를 해결해보자. 이 문제 중 두번째 문제가 당근마켓 그룹플랫폼 인턴직무의 사전 질문이었다...! 이걸 직접 해결해 볼 수 있는 기회가 이렇게나 빨리 오게 될 줄이야.... https://0422.tistory.com/331 당근마켓 윈터테크 인턴십 그룹플랫폼 직무면접 불합격 회고 그룹 플랫폼 팀에 지원 이번 윈터테크 인턴십은 프론트엔드가 코어, 광고, 그룹플랫폼 3가지 형태로 구성되어있었다...

이전글에서 무한스크롤에 필요한 두가지 조건을 정리했다. 사용자가 페이지 하단에 도달했을때 콘텐츠가 계속 로드 첫번째 조건은 이전글에서 완료했으니, 2번째 미션을 해결할 차례다. 어떻게 콘텐츠가 계속 로드되게 만들 수 있을까? 데이터를 페이지네이션 형태로 제공하는 방법은 크게 cursor 기반과 offset 기반, 두가지 방법이 존재한다. 하지만 그것은 백엔드 개발자의 일이구요... 라고 하면 큰일나니 간단하게 알아보자. offset 기반 페이지단위로 구분해서 구현이 간단하나 데이터 중복문제(중간에 글이 써지는경우)가 발생한다. offset값이 커지면 앞의 데이터를 모두 읽어야해서 DB상 성능문제가 발생할 수 있다. cursor 기반 cursor라는 사용자에게 마지막으로 응답해준 마지막 데이터 식별자 값을..

배경 커뮤니티 서비스를 만들고 있는데, 피드를 만들어야 했다. 이전에 당근마켓 인턴십의 사전 질문이기도 했던 세부 글보기 에서 좋아요/댓글이 추가/삭제된 경우 어떻게 피드에 반영할 것인가?라는 질문에 직접 구현해보며 답할 수 있는 좋은 기회라고 생각해서 구현하게 됐다. 무한스크롤에 필요한 것들을 하나씩 확인해보면서 구현할 것이다. 필요한 것 알아내기 무한 스크롤은 사용자가 페이지 하단에 도달했을때 콘텐츠가 계속 로드되는 사용자 경험 방식이다. 그럼 구현에 필요한 두가지 필수 조건을 알 수 있다. 사용자가 페이지 하단에 도달했을때 콘텐츠가 계속 로드 이 두 가지 미션을 해결하면 무한스크롤이 되는 것이다. 이 게시글에서는 1번 항목에 대해 어떻게 구현할 것인지를 고민해보았다. 사용자가 페이지 하단에 도달했음..

https://0422.tistory.com/347 React, RN 환경에서 WebView 통신하기 (react-native-webview) 배경 웹뷰를 사용하여 앱을 구성하고 있다. 웹뷰는 마치 HTML의 iframe 태그처럼, 내부적으로 하나의 화면을 띄우는 형태이다. 그런데 우리 서비스의 로그인 로직은 앱에 있어서, 웹에서 따로 로그 0422.tistory.com 위 글에서 이어진다. 이전 게시글을 통해 앱-웹간 통신으로 토큰을 받아오고 이벤트를 발생시키는 것까지는 완료했다. 하지만 이제부터 시작이다. 받아오기전에는 어떻게 하고, 받은 토큰을 어떻게 관리할 것인가? 토큰을 받아오기 전에는? 토큰은 앱의 onLoad를 통해 주입되지만, 이 이벤트가 동기적으로 작동하지는 않는다. 따라서 웹 화면은 로..