다짐 - 알보칠 프로젝트

다짐이 네이티브에서 리액트 네이티브로 전환한 이유

스토어에 올라간 앱을 새로운 앱으로 교체하기 기존 네이티브로 제작된 앱을 RN으로 새로 구축하기로 결정한 뒤, 가장 먼저 한 고민은 '어떻게 전혀 다른 앱을 동일한 앱처럼 보이게 할까'였다. 겉보기에는 똑같아 보이는 앱이라도 새로이 프로젝트 init부터 시작하는 프로

앱 교체 후에도 로그인 유지하기 다짐을 RN으로 교체하는 알보칠 프로젝트를 시작한지 얼마 안된 시점, 내 정신적 멘토인 bang9 형님이 "로그인 유지 작업은 당연히 할 예정이지?"라고 물어왔다. 사실 로그인 유지쪽은 전혀 생각지도 못했고 '앱이 아예 갈아끼워지는데 그

나는 새로운 앱을 만들 때 가장 먼저 네비게이션 구조부터 설계하는 편이다. 네비게이션은 가장 기본적인 Stack Navigation부터 Bottom Tabs Navigation, Drawer 등 여러가지 종류가 있는데, 구현하고자 하는 앱의 형태에 따라 여러개의 nav

TS와 RN Navigation react native navigation을 사용하다보면 생각보다 type에 엄격하다는 사실을 알 수 있다. 대표적으로 typescript를 쓰면서 generic 없이 그냥 useNaivgation을 사용하면 screenName의 타입을

로그인 가딩이 필요한 이유 다짐은 기본적으로 로그인이 없어도 앱의 대다수 컨텐츠에 접근 가능한 형태의 서비스다. 따라서 아무런 제약 없이 앱을 이용하다가, 결제, 상담, 찜 등 로그인이 필요한 기능을 사용하려고 할 때 로그인을 요청하게 된다. 즉, 로그인 여부와 관계

알보칠과 디자인 시스템 다짐을 React Native로 새롭게 구축하는 알보칠 프로젝트 진행이 결정되고 가장 먼저 해보고 싶었던 건 바로 '디자인 시스템 구축'이었다. 사실 디자인 적으로는 이미 Figma에 디자인 시스템이 정리되어 있던 상태였다. 하지만 사내 구축된

컴포넌트의 분리와 결합 비슷한 컴포넌트를 만들 때 분리해서 각각 구현할 것인지, 아니면 하나의 컴포넌트로 구현할 것인지 결정하는 일은 얼핏 쉬운 일처럼 보여도 꽤나 자주 나를 고뇌에 빠뜨렸던 주제였다. 다짐의 Button 컴포넌트와 Text Card 컴포넌트를 가져와

직전 글에서 다짐의 DgText를 사례로 이야기를 풀어갔었는데, 이번에는 잠깐 쉬어가는 느낌으로 Text 컴포넌트를 실제로 어떻게 구현해서 쓰고 있는지 공유해보려고 한다.

왜 다짐의 디자인 시스템을 서브모듈로 분리했을까 깃헙에는 서브모듈이라는 기능이 있다. 간단하게 설명하자면 main project directory 내부에 다른 repo를 추가해서 N개의 repo를 하나의 프로젝트에서 함께 관리하는 개념이다. 조금 더 쉬운 이해를 위해

구현해놓은 모든 Modal을 갈아 엎었던 이유 다짐 알보칠 프로젝트(다짐을 RN으로 처음부터 다시 만드는 프로젝트) 막바지에 이르러서 지금까지 구현했던 모든 Modal component를 갈아엎는 결정을 했다. 여기서 표현하는 '갈아엎었다'는 크게 두가지 관점에서 진행

Modal contents를 전역 상태로 핸들링하기(with zustand) 지난 시간에 이어, 이번에는 모달에 보여지는 컨텐츠를 전역상태로 핸들링해보도록 하겠다. 다짐에서는 zustand를 전역상태 라이브러리로 채택하고 있기 때문에 zustand를 기준으로 설명하겠지

Promise로 Custom Modal 강화하기 이제 길고 길었던 Modal Refactoring 마지막 파트다. 이번에는 Promise를 활용해서 modal action을 처리하는 방식으로 뷰와 로직을 분리하는 작업을 해볼 예정이다. 개인적으로 이 작업을 하면서 시야

웹뷰란 모바일에서 웹페이지를 띄우는 기술을 말한다. 보통 모바일로 구현하기 까다로운 기능을 가진 페이지나, 높은 빈도로 재배포되어야 하는 페이지들을 웹뷰로 띄우는 결정을 하며, 웹뷰는 코드 재사용성, 유지보수성 측면에서 모바일 대비 강점이 있다. 때문에 전략적으로 일부

Loading의 시각화와 사용성 개선 network 통신 없이 앱을 구현하는게 아닌 이상 Loading은 필연적으로 마주할 수밖에 없다. 그리고 Loading은 서비스의 사용자 경험을 저해하는 주요 원인 중 하나다. loading이 길어지거나, loading 상황에 유

Loading의 제거 이전 글에서는 사용자에게 Loading을 시각화하여 보여주는 케이스에 대해 다뤘는데, 사실 대부분의 경우 loading은 제거할 수 있다면 제거하는 게 무조건 좋다는 것에 이견이 없을 것이다. 그래서 이번에는 반대로 로딩을 어떻게 최소화할 수 있는