분류 전체보기

배경 웹뷰를 사용하여 앱을 구성하고 있다. 웹뷰는 마치 HTML의 iframe 태그처럼, 내부적으로 하나의 화면을 띄우는 형태이다. 그런데 우리 서비스의 로그인 로직은 앱에 있어서, 웹에서 따로 로그인/로그아웃을 구현하지 않고, 앱 내부의 JWT토큰을 웹으로 전달할 수 있어야 했다. 또한 웹내에서 JWT토큰이 만료되는 경우 로그인 페이지로 이동시켜줄 필요가 있었다. 우선 Web과 App환경의 통신 방법에 대해 알아보고, 이후에 토큰을 내부적으로 관리해볼 것이다. 기본 구성하기 기본적으로 react-native-webview 라이브러리를 사용해서 WebView 화면을 띄워주었다. https://www.npmjs.com/package/react-native-webview react-native-webview..

Indexed Carousel 이제 Index 기반의 Carousel을 구현해보자. 사실 로직은 이전 글과 거의 동일하다. 시작 터치 위치를 기억하고, 움직일때 transX를 변경하고, transX를 기반으로 translateX를 통해 스크롤을 구현한다. 여기서 Index를 추가하고, 특정 scroll값을 넘으면 인덱스를 변경시켜 주고, translateX값을 Index기반으로 작동하도록 만들어주면된다. 그래서 handleTouchStart와 handleTouchMove콜백함수는 Non-Indexed와 동일하다. // Non-Indexed와 동일하다. const handleTouchStart = (e: React.TouchEvent) => { setTouchStartX(e.touches[0].client..

문제상황 Teengle 프로젝트는 웹뷰프로젝트로, 모바일 기기에서 실행되어야하다보니, 여러 정보를 작은 화면에서 조회하기위해서 상당히 많은... Carousel이 필요했다. Non-Indexed Carousel 첫번째 Carousel은 커뮤니티 피드에서 마치 스레드처럼 여러개의 사진을 볼 수 있는 기능에 필요했다. 이 Carousel은 아래 사진 처럼 스크롤한 만큼 자유롭게 이동이가능해야했다. 그냥 overflow scroll로 구성해서는 스크롤 속도가 너무 빨라서 사용할 수 없었다. Indexed Carousel 두번째 Carousel은 투표기능에서 여러 투표를 슬라이드를 통해 확인하기 위해 필요했다. 이 Carousel은 스크롤시에 요소를 중앙으로 배치시켜주어야 했기에 Non-Indexed와 로직은 ..

배경 새로운 프로젝트는 많은 사용자들이 모바일 환경에서 사용할 수 있도록 앱 형태를 택했다. 또, 플레이스토어/앱스토어에서의 업데이트 없이, 실험을 통해 앱을 지속적으로 빠르게 업데이트해보고자 그 중에서도 웹뷰를 선택하게 되었다. 사실 웹뷰는 토스/당근에서 다양한 실험/빠른 업데이트 때문에 사용한다는 이야기를 들은 뒤부터 사용자에게 정말 유효한 가치를 전달하려면 꼭 필요한 기술이라고 생각해서 꼭 한번 도전해보고 싶었다. 문제 웹뷰 화면 설계를 이야기 하지 않을 수가 없다. 웹뷰, 아니 앱의 문제점중 하나라고 한다면, 바로 스토어 리젝이다. https://orangebrother.dev/blog/app_why_reject iOS / Android 앱 심사 시에 발생하는 Reject 사유들 앱을 배포하기 위..

들어가며 프렌딩에서 프로필 교환 관련 개발을 하고있었다. 여기서 프로필 교환이란, 나와 상대의 프로필 카드를 교환하는 것이다. 마치 명함을 교환하는 것처럼 말이다. 그런데 여기서 약간의 문제가 생겼다. 앱인 경우에는 프로필 공유를 하게되면, 해당 프로필을 가진 사람의 기기에 푸시알림을 보내서 친구추가를 하는 형태였지만, 앱을 설치하지 않은 사람이 설치한 사람의 프로필 링크를 받거나, QR을 찍는 경우 어떻게 할지가 고민했다. 결론은 앱을 설치하지 않은 사용자의 경우 웹을 띄워서 어떤 프로필인지 볼 수 는 있게 해주자 였는데, 이걸 어떻게 안전하게 구현할 수 있을지가 고민이었다. 그냥 프로필 id로 보여주면 되는거 아님? 웹링크는 랜딩 사이트를 이미 개발했고, 배포해두었기때문에, 랜딩 사이트의 url을 사..

2023년이 끝나간다. 되돌아보면 2023년에는 정말 많은 경험들을 할 수 있었던, 뜻깊은 한 해였다. 되돌아보기 안녕, 멋쟁이사자처럼...! 이번 년도의 목표는 성장하는 조직을 만들어 보는 것 이었다. 그래서 작년에 운영진을 지원한 것이기도 하다. 고등학교때 반장을 매년하긴했었지만, 나는 뭔가 주도적으로 기획하고, 이끌기보다는 다른 친구들이 하자고 하는대로 의견을 조율하는 형태로 일을 진행했어서 기획을 해본 경험이 없었다. 그래서 운영진으로써 멋사를 처음 시작했을때는 어떻게 해야할지 모르는, 다소 막막한 상태였던 것 같다. 이때 다른 운영진들, 특히 프론트엔드 운영진들이 많이 도와줘서 그 방향성을 잡을 수 있었다. 1학기 성장하는 조직을 만들기 위해 세션 후에 회고하고, 이를 공유하는 문화를 만들기 위..

문제점 성능을 측정해보기 위해 lighthouse를 사용하던 중 점수대가 심상치 않다는 것을 알게되었다. 무려 79점...이었다. 문제파악하기 우리 AlgoITNi는 Home과 Room 두가지 페이지로 구성된다. 대부분의 기능은 Room에 필요하고, Room에서만 사용한다. 그러나, 리액트는 SPA이기에 이런 모듈들을 Home을 렌더링할때도 가져오게되고, 따라서 Home의 초기렌더링 성능이 나빠지는 것이라 추측했다. 확인해보기 프로덕션에서는 빌드가 완료된 청크가 네트워크 응답으로 오기때문에 정확하게 분석하기 어렵다. 따라서 개발환경에서 Home에 접속했을때 개발자도구의 네트워크 탭을 통해 어떤 코드를 불러오는지 확인했다. 빨간색 부분이 Room에서 필요한 코드들이다. 즉, Home에 접근했을때는 필요없는..

문제점 네이버 부스트캠프에서 진행하고 있는 AlgoITNi프로젝트에서 아래와 같은 문제가 발생했다. 빌드하는 과정에서 이러한 경고 메시지가 발생한 것이다. 특정 청크가 500KB보다 크다는 것이 문제이다. 위 사진을 보면 번들사이즈가 1285kb이고, 사용자가 실제로 받는 번들사이즈인 gzip사이즈가 425.33kb이라 초기 렌더링이 느려질 수 있다는 문제가 있다. 청크 사이즈 줄이기 청크 구조 분석하기 원인을 알기위해서 vite-bundle-visualizer를 사용해서 청크의 시각적인 분석을 해보았다. highlight.js가 번들의 절반을 차지하고있었다. highlight.js는 에디터에서 코드하이라이팅에 사용되는 라이브러리인데, 여러가지 언어를 모두 지원하기때문에 이렇게 라이브러리 사이즈가 커지는..

그럼 이걸 활용해서 yml을 만들어보자. Github Actions Github Actions는 github에서 제공하는 CICD 툴으로써, 코드 저장소에 어떤 이벤트가 발생했을때 특정 작업을 일어나게 하거나 주기적으로 작업을 반복 실행시키는 일을해준다. 이에 따라 브랜치마다 다른 일을 할 수 있도록 처리해줄 수 있다. 그럼 브랜치마다 어떻게 작동하게 만들지 전략을 수립해보자. 배포 브랜치 전략 수립하기 우리팀은 프론트엔드 코드와 백엔드 코드가 한 레포지토리에 있기때문에, 각 파트별 배포가 필요한 상황이었다. https://github.com/boostcampwm2023/web05-AlgoITNi GitHub - boostcampwm2023/web05-AlgoITNi: 동료와 함께 할 수 있는 플랫폼, ..

CICD를 구성하기전에 우선은 배포를 위한 서버 자원(S3, CloudFront, IAM)을 생성하고, AWS CLI를 사용해보자. S3만들기 클라우드 프론트를 통해 OAC설정을 할것이기에 ACL비활성화, 퍼블릭 엑세스 차단설정을 해도된다. CloudFront배포 만들기 원본 도메인으로 S3 버킷을 연결시켜주자. OAC설정하기 클라우드 프론트로만 S3에 접근할 수 있도록 S3의 정책을 변경해주자 S3에 파일을 업로드 하기 웹 콘솔에서 업로드 버튼 누르기 사실 업로드하는 방법은 간단하다. AWS 콘솔에서 업로드 버튼을 누르면 된다 허허 그런데 git에 push 할때마다, 직접 빌드하고 빌드한 파일을 업로드 하기에는... 우리는 너무 할일이 많고, 충분히 자동화시킬 수 있는 부분이다. 그래서 github a..