전체 글528 [React] 예약 실패 → PDP 새로고침, 브라우저 간 메시지 통신으로 해결하기 📍 예약 실패 → PDP 새로고침, 브라우저 간 메시지 통신으로 해결하기문제 상황놀앱으로 예약생성 실패 알럿 클릭시 현재 페이지(예약결제페이지)가 닫히고 PDP페이지로 돌아오게 된다. 이때 PDP는 상품의 최신 정보(상품/옵션/아이템 판매 가능, 가격 등)를 다시 불러와야한다. 그렇지않으면 유저는 예약이 불가능했던 기존 스냅샷 정보를 계속 사용하게되어 좋지못한 UX를 경험하게 된다.대안 분석visibilityChange 이벤트 활용장점: 간단한 구현 (페이지가 다시 활성화 될 때 상품 정보 API 호출)단점: 예약 실패 상황과 무관하게 단순히 탭 전화만해도 API를 호출하게 된다. 이는 실시간으로 조회하는 API 특성상 불필요한 네트워크 비용이 발생하게 되어 서버/클라이언트 모두 부담이 크다.useEf.. 2025. 9. 28. [React] 쿠폰 전체 받기 기능을 개선해보자! 📍 쿠폰 전체 받기 기능을 개선해보자!문제 상황상품 상세 페이지(PDP) 내 쿠폰받기 팝업에서 쿠폰 전체 받기 버튼 클릭시, 일부 유저가 쿠폰 다운로드 실패 알럿이 반복적으로 노출된다는 CS 접수되었다. 즉, 사용자는 전체 쿠폰 받기 버튼을 눌렀는데 실제로는 다운로드가 일부 실패하거나 에러 메시지만 보는 상황원인 분석DataDog에서 쿠폰 다운로드시 호출되는 베네핏 API 확인. 에러로그를 살펴보니 문제가 발생한 시점에 0.1초 간격으로 할인 쿠폰이 이미 발급되었습니다. 에러로그가 찍혀있는것을 발견함.(01:12:00.520, 01:12:00.521, 01:12:00.522, 01:12:00.525 ...) 그러나 프로그램을 사용하지 않는 이상 유저가 0.1초 간격으로 다운로드 버튼을 누를 수 없기때문.. 2025. 9. 15. [사내발표] 타임 아웃 처리로 Braze Feature flag 로딩 UX 개선하기 Braze Feature flag 로딩 타임 아웃 처리로 UX 개선하기문제 상황Braze 툴로 A/B 테스트를 구현하는데, braze initialize 후 getFeatureFlag() 호출 시점에서 featureFlag 데이터가 준비되지않아 undefined가 반환되는 이슈가 발생했다. 이로인해 FeatureFlagProvider 내부에서 children이 null로 반환되어 페이지 전체가 렌더링되지 않는 문제가 있었다.접근/해결 방식재시도 로직 추가: feature flag가 없을 경우 refreshFeatureFlags 메서드로 한번 더 호출타임아웃 설정: 네트워크 지연으로 인한 무한 대기를 방지하기 위해 최대 대기 시간 설정로딩 상태 관리: 사용자에게 로딩 중임을 알리고, 타임아웃 후에는 기존 .. 2025. 8. 20. [사내발표] Safari 애플 로그인 이슈 극복기(feat. firebase) ( 이 글은 사내에서 발표한 자료를 바탕으로 작성했습니다. ) 트리플 서비스를 100% 이용하고 싶을 때 필수로 거쳐야 하는 관문이 하나 있습니다. 바로 로그인인데요. 트리플에서는 5가지 방법(이메일, 카카오, 네이버, 페이스북, 애플)으로 로그인할 수 있고, 다양한 방식의 로그인을 쉽게 사용하도록 도와주는 firebase를 사용하고 있습니다. 이처럼 트리플에서는 firebase의 도움을 받아 다양한 로그인(이메일 / 비밀번호 기반 인증, ID 공급업체 인증, 전화번호 인증, 커스텀 인증 등)을 쉽고 빠르게 구현할 수 있었습니다. firebase API Reference를 살펴보면 카카오와 네이버는 커스텀 인증(signInWithCustomToken)을 사용하고, 애플만 ID 공급업체 인증방식(sign.. 2025. 8. 14. [사내발표] CHANGELOG 자동화하기 ( 이 글은 사내에서 발표한 자료를 바탕으로 작성했습니다. ) 개인 프로젝트 혹은 다른 동료와 협업을 할 때 각 버전에 맞는 변경사항을 시간순서대로 작성하기 위해 우리는 CHANGELOG.md 파일을 이용하고 있습니다. 덕분에 기계가 아닌 사람들(개발자 혹은 User)이 해당 프로젝트의 각 릴리즈 버전 간의 차이점을 한눈에 파악해 어떤 점이 왜 바뀌었는지 명확하게 알 수 있습니다. 기계가 아닌 사람이 필요로 하기 때문인지는 몰라도 매번 프로젝트의 버전이 바뀔 때마다 직접 손으로 작성합니다. 버전을 드문드문 (예를 들면 2주에 한 번 정도..)변경한다면 불편함이 없겠지만, 팀원이 많거나 FEATURE/FIX 작업이 많을 때 3일에 한 번 혹은 하루에 한 번씩 버전을 변경하는 때도 있습니다. (최근 TF에.. 2025. 8. 14. 이전 1 2 3 4 ··· 106 다음
