Sep 14, 2023 (강남역 오프라인 3주차)
모바일 페이지의 페이지 레이아웃은 어떻게 잡는 것이 좋은가?
- 간단한 페이지를 할 때는 뷰포트(vw, vh)를 사용해도 괜찮다.
- 하지만 뷰포트를 사용하면 리사이징 문제가 생김 (모바일 장치를 회전하면? → 동적으로 뷰포트를 수정해주면 되긴 함)
- 콘텐츠가 뷰포트를 넘어가면 스크롤이 필요해짐
- Grid를 사용하는 것이 좋다.
- 복잡한 레이아웃, 다양한 화면 크기를 지원 등
- 또 어떤 방식으로 레이아웃을 잡는가? flex는 너무 더럽고 복잡해지는데… 흠.
JWT 토큰을 로컬 스토리지에 저장하고 있는데, 이것은 어떤 문제를 야기할까?
- 우리 프로젝트의 백엔드에는 JWT 토큰을 주고, 로그인에 사용하도록 되어 있다.
- 로컬 스토리지에 저장할 경우, XSS 공격, CSRF에 취약함! 로컬 스토리지를 사용하면 매우 편리하지만 보안에 위험이 있다.
- 다른 방법으로 쿠키에 HTTPOnly 쿠키로 설정하여 사용하기도 하는데, 보안에 위험이 있는 것은 마찬가지이지만 공격자가 조금 더 까다로울 수 있고 몇 가지 공격을 회피할 수 있는 스킬들이 있다고 한다. 많이들 사용하는 방법인 것 같다.
- 메모리(변수)에 저장하는 방법도 있고.. 여러 방법이 있다. 다른 팀에서는 상태관리 라이브러리로 관리를 하는 곳도 있었다.
모달을 어떻게 관리할 것인지에 대해서
- 우리 리액트 프로젝트에는 Context API를 사용하고 있는 상황이다. AuthContext를 만들어서 사용자 권한 컨텍스트를 적용 중이다.
- 나는 공통 컴포넌트로 Modal 컴포넌트를 만는데, Modal 컴포넌트는 2가지 형태와 (info | confirm) 모달의 내용과 확인 버튼 클릭시의 로직을 프로퍼티로 받도록 구상하고 있다.
- 모달이라는 컴포넌트는 특정 페이지에서만이 아닌 전체 페이지에서 뜰 수 있을 것으로 예상된다. 모달에 대한 컨텍스트를 만들고 전역적으로 상태를 관리해야 하는 것이 아닐까?
- 만약 그렇게 한다면 렌더링 측면에서는 비용이 어떻게 되는 걸까?
Sep 16, 2023
모바일 정렬을 어떻게 할까?
- 스크롤이 필요하지 않고 요소들이 가로 세로의 중앙에 위치해야할 때, 어떻게 해야할까 고민
토스트 컴포넌트의 UI
- 이거는 데이지 쓰자…
Sep 20, 2023
토스트 컴포넌트의 UI (2)
- 데이지UI를 커스텀해서 전체 페이지와 결이 같은 디자인을 만들었다.
토스트 사용 기능
- daisy ui를 커스텀해서 만든 토스트 컴포넌트를 어떻게 사용할 수 있을까?
- Context API 혹은 전역 상태 관리 라이브러리를 사용해야 한다.
- useState로 토스트를 사용하는 방법은 원초적이며 추상화되지 않아 사용할 때마다 상태를 정의하고 조건문으로 렌더링시키게 된다. 해당 로직이 컴포넌트에 속하게 되며 컴포넌트의 생명주기에 영향을 받게 된다.
- Context API로 토스트 컨텍스트를 만들고, 토스트를 선언적으로 사용할 수 있도록 개발했다.
- 모달은 전역 상태로 관리하지 않았는데, 이 부분도 리팩토링해야 할 것 같다.
Context API와 createPortal
- 각자 렌더링 관점에서 어떻게 활용해야 하는가?
- Context API는 전역 상태 관리에 필요하고, createPortal은 컴포넌트의 렌더링 위치를 제어한다. 또한 createPortal은 리렌더링을 줄일 수 있기도 하지만 주 목적이 아니다. 전반적으로 컴포넌트의 성능을 최적화하기 위해서는 다른 기술과 최적화 기법을 사용해야 한다고 한다.
- 토스트 사용을 위해 Context API와 createPortal을 모두 사용했는데, 이것이 어떤 영향을 주는 지 알아보아야 될 것 같다.
Sep 21, 2023
CSS에 대해서
- CSS 이해도, 실력이 너무 부족하다.
- grid를 결국 사용하지 못했다. CSS를 하나 하나 배우면서 하기에는 마감이 벅차서 부랴부랴 어떻게든 만들고, 어떻게든 tailwind 클래스 네임을 붙여가면서 만들었다.
- tailwind css를 마구 마구 사용하기 전에, CSS에 대한 이해가 깊어야 할 것 같다.
- 전체 페이지들에 대한 레이아웃 다듬는 작업을 결국 목업 페이지 만드는 날로 미뤘다.
- 레이아웃이 적용되는 페이지에 패딩과 마진을 남발하지 말자. 레이아웃이 깨져버린다. 공통 컴포넌트에는 컴포넌트 바깥에 여백이 있으면 안되고, 페이지에서는 grid와 flex를 사용해야 한다. 그리고 페이지를 개발하기 전에 html 요소들을 정리한 뒤에 개발해야 편하다.
기획 단계 디자인과 다크모드 적용
- 처음 기획 단계에서의 디자인에서 모든 페이지에 대한 다크모드 디자인이 나오지 않았고, 자잘한 수정 사항들이 생겨 기획 단계의 디자인과 완벽히 같은 결과물이 나오지 않았다. 혹여나 다음에 또 피그마를 만지고 디자인할 기회가 생긴다면, 기획 단계에서부터 수정 사항이 나오지 않게끔 완전함에 가깝게 디자인해야 할 것 같다. 색상 팔레트부터 컴포넌트들의 사이즈와 간격까지. 실제로 개발해야 하는 모바일 디자인은 처음해보다 보니 놓친 부분이 너무 많다.
- tailwind css에서 다크모드를 지원하는 부분이 정말 편하다.
- 다음에는 적용하기 쉽도록 각 색상이 어떻게 1:1로 대응되는 지 기획 단계에서부터 정의가 되어 있어야 할 것 같다.
협업에 대해서
- 사전에 정의, 사전에 협의, 사전에 정리
- 첫 협업인 만큼 부족한 점이 너무 많았다. 그래, 사전에 정의하고 도중에 협의하는 과정에서도 ‘무엇을’ 주제로 이야기해야 하는 지 놓친 것이 많다. 유저 스토리와 기획/디자인 부분에서 훨씬 상세하게 정의하고 들어가야 된다! 그때 그때 수정하면 완성도가 너무 떨어진다.
- 이번 프로젝트에서 나는 서버 관련 데이터 로직을 가공해서 보여주는 페이지들을 많이 담당하지 않았다. 팀원들이 맡은 페이지에서 발생하는 문제들을 보면서 함께 해결책을 강구했다. 다음에는 직접 맡아서 해보고 싶다.
목업 디자인 해야됨
- 위 이미지와 같은 느낌으로다가.