2020.11.30(월) 회의록

2020.11.30(월) 회의록

의제

1. React Router Uri 설계

• 로그인 페이지(가장 첫 화면): /login

• 가계부 선택 페이지(로그인 이후 페이지, root): /

• /accountbooks는 쓰지 않되, 사용자가 혹시나 해당 uri로 접근하면 root uri로 리다이렉트시킨다.

• 가계부 관리 페이지: /accountbooks/:id/settings

  • 가계부 설정: /accountbooks/:id/settings/accountbook
  • 카테고리 관리: accountbooks/:id/settings/categories
  • 결제수단 관리: accountbooks/:id/settings/accounts
  • 소셜: /accountbooks/:id/settings/social
  • CSV 파일 관리: /accountbooks/:id/settings/csv

• 거래 내역 페이지: /accountbooks/:id

• 달력 페이지: /accountbooks/:id/calendar

• 통계 페이지: /accountbooks/:id/statistics

2. Filter정보도 URL에 저장해야 할까?

• 논의되는 이유: 사용자가 브라우저에서 뒤로가기를 눌렀을 때 이전에 적용했던 필터가 적용된 거래 내역이 보여야 할지 말지에 대해 고민 중이다.

  • 근거: 깃허브 이슈트래커를 기준으로 보면, 특정 필터를 적용한 후 브라우저에서 뒤로가기를 누르면 이전에 적용했던 필터가 적용된 이슈 목록(적용했던 필터가 없었으면 아무 필터가 적용되지 않은 이슈 목록)을 보여준다. 즉, 필터에 관한 내용까지 URL에 담고 있다.

  • 어려운 점: url에 넣었을 때 잘 관리가 될 수 있을까 고민이다. 해본 적이 없어서 쿼리문이 들어간 동적인 url을 관리하는 방법에 어려움을 겪는 중... 우선은 3주차에서 개발할 사항은 아니므로 보류.

  • 대안: Mobx에 저장하고 관리한다. 단, 이 경우 이전에 적용했던 필터들은 저장하지 않고 가장 최근에 적용한 필터의 상태만 저장한다.

안건에 대한 의견 및 결론

• 필터 정보를 URL로 관리할 때 흐름

  1. 필터 모달에서 필터 조건을 선택한 다음 적용 버튼을 누르면
  2. 필터 조건이 담긴 데이터를 쿼리 형식으로 바꾼 후 ex) ?start_day=20201101&end_day=20201130&expenditure_categories=식사+교통
  3. 해당 쿼리를 거래 내역 uri(/accountbooks/:id) 뒤에 붙인 후, 완성된 url을 history.push로 저장한다.
  4. 필터 조건에 맞춰 거래 내역을 가져오는 API를 호출하고, 반환값을 Mobx Transactions Store에 저장한다.
  5. Transactions List 컴포넌트가 Transactions store에 있는 데이터를 가져와
  6. React Router에 따라 이동된 URL에서 정규식을 활용하여 category 등 필터 조건들을 추출한다.
  7. 필터링 조건에 맞춰 Transactions List에서 거래 내역을 렌더링한다.
  
  

• 필터 정보를 Mobx로 관리할 때 흐름

  1. 필터 모달에서 필터 조건을 선택한 다음 적용 버튼을 누르면
  2. Filter Store에 필터 조건 내용들로 상태를 갱신한다.
  3. Filter Store의 상태값이 갱신될 때, 해당 필터 조건에 맞는 거래 내역을 가져오도록 API를 호출한다.
  4. API의 반환값을 Transcations Store의 상태값으로 갱신한다.
  5. Transactions Store의 상태값을 관찰하고 있는 Transaction List 컴포넌트는, 상태값이 갱신될 때 리렌더링한다.

• 결론
  • url로 관리하자.

3. 다른 가계부의 Filter정보도 URL에 저장해야 할까?

• 논의되는 이유: 사용자가 A 가계부에서 B 가계부로 빠져나갔다가 다시 A 가계부로 이동했을 때, 빠져나가기 직전의 A 가계부 화면을 보여줄 것인가에 대해 고민 중이다.

• 근거: 슬랙같은 경우 A 채널에서 특정 스레드를 열어둔 채 B 채널에 들어간 후 다시 A 채널에 오면 A 채널에서 열어둔 특정 스레드 화면이 그대로 보인다.

• 멘토님께 질문드린 DM 내용

안녕하세요 멘토님들. 저희 조에서 페이지 상태에 대해서 토론하던 중 궁금한 점이 생겨서 질문 드립니다.

본격적인 질문에 앞서 알아주실 사항을 간략히 정리하면 다음과 같습니다.

• 개인은 다수의 가계부를 소유할 수 있습니다.
• 각 가계부에 대해 상태를 둘 것인지, 현재 가계부에 대한 상태 하나만을 둘 것인지에 대해 의논 중입니다.

사용자 스토리로 설명드리겠습니다. 가령, 1번 가계부에서 특정 필터를 적용하여 필터링된 거래 내역을 보여주고 있습니다. 이후, 2번 가계부로 이동하여 특정 행동을 취한 후 1번 가계부로 이동합니다. 여기서 1번 가계부로 다시 이동했을 때, 2번 가계부로 이동하기 이전에 적용되었던 필터링 된 거래 내역을 보여줄 수 있게 각 가계부의 상태를 저장하는 것이 맞는 것인지 고민 중입니다.

UX 측면에서는 각 가계부의 상태를 가지고 있는 것이 맞다고 생각되오나, 이제 실질적으로 개발할 수 있는 기간이 얼마 남지 않은 터라 상태 관리에 너무 많은 시간을 소요하게 될까 걱정이 듭니다. 현업에서는 어떤 방식으로 진행하고 있는지, 그와 별개로 현실적으로 멘토님들은 어떤 방식으로 구현하는 게 적합하다고 생각하시는지 의견을 여쭙고자 합니다.

감사합니다. -D조 일동-

• 멘토님이 답변해주신 DM 내용

두 가지를 결정해 주신 배경을 알 수 있을까요? ㅎㅎ 물론 잘 구현되면 좋은 기능이 될 것 같고, 각 항목마다 설게와 구현 기법은 한 가지만 존재하는 것은 아닙니다.

1. 개인은 다수의 가계부를 소유할 수 있습니다.
2. 서로 다른 가계부를 오갈 때에도 각 가계부의 상태를 유지합니다.

• 어떤 과정을 통해 결정되었나요?
• 꼭 필요한가요?
• 벤치마킹하신 서비스가 그러하기 때문인가요?
• 벤치마킹하신 서비스가 그러하지 않다면, 왜 그런 결정을 내렸을까요?

• 멘토님의 질문에 답변드린 DM 내용

1. 개인은 다수의 가계부를 소유할 수 있습니다.
2. 서로 다른 가계부를 오갈 때에도 각 가계부의 상태를 유지합니다.

• 어떤 과정을 통해 결정되었나요?

  1. 카카오뱅크의 공동 모임 계좌 서비스를 벤치마킹했습니다. 카카오뱅크의 공동 모임 계좌 서비스를 생각해보면, 저희가 구현 중인 소셜 기능이 가미된 가계부 서비스에서도 1인 당 1개의 가계부만을 작성하는 것은 바람직하지 못하다고 판단했습니다.

  2. 슬랙같은 경우, A 채널에서 특정 스레드를 열어둔 채 B 채널에 들어간 후 다시 A 채널에 오면 A 채널에서 열어둔 특정 스레드 화면이 그대로 보입니다. UX 측면에서 다른 채널 간의 이동 시, 이전 채널에서 활동하고 있던 것들이 초기화된다면 불편할 것이라고 생각했습니다.

     약간 다른 이야기지만, 동일한 가계부 안에서도 '내역' 탭과 '통계' 탭, '달력' 탭 간의 이동 시에도 필터링 상태가 저장되어야 한다고 생각했습니다. 뱅크샐러드의 경우도 '가계부' 탭에서 필터링을 적용한 후, '건강' 등의 탭으로 이동했다가 다시 '가계부' 탭을 오게 되면 적용했던 필터링이 남아 있습니다.

• 꼭 필요한가요?

  1. 위에서 언급했듯 소셜 기능이 추가될 것이라면 한 개인이 다수의 가계부를 소유하는 것은 저희 프로젝트의 주요 기능 중 하나라고 생각합니다. 하지만 소셜 기능이 추가되지 않는다면 꼭 필요하지는 않습니다.
  2. 필수적인 기능은 아니지만 사용자가 설정한 각 가계부 설정 필터가 계속 유지된다면 편리할 것이라고 생각했습니다. 하지만 본 글에도 말씀드렸다시피 사용자의 편의성을 증진시키는 부가 기능에 너무 많은 시간을 할애하는 것은 아닐까 걱정을 하고 있는 중입니다.

• 벤치마킹하신 서비스가 그러하기 때문인가요? / 벤치마킹하신 서비스가 그러하지 않다면, 왜 그런 결정을 내렸을까요?

  • 위에 언급한 답변에 녹아있다고 생각하여 답변을 생략하겠습니다.

멘토님의 질문에 대한 답과 더불어, 2번 사항을 구현했을 때와 구현하지 않았을 때 어떤 비용과 어떤 이점이 있는지 생각해봤습니다.

• 2번 사항을 도입하게 될 경우 비용 및 특징

  • 프론트 엔드에서 상태 관리

    • 유저가 소유한 n개의 가계부 각각의 상태를 관리해줘야 하므로, 상태 관리의 복잡도가 증가한다.

  • 세션으로 각 가계부 필터 관리

    • 필터 내용이 서버 메모리에 할당된다.
    • 필터링이 적용된 거래 내역을 렌더링해줘야 할 때, 서버에 API를 보내 세션을 조회해야 한다.
    • 특정 가계부에서 필터가 바뀔 때, 서버에 API를 보내 세션을 수정해야 한다.
    • 세션을 도입했을 때가 프론트 엔드에서 n개의 가계부 상태를 각각 관리하는 것보다 쉬울것 같다는 생각이 든다.

  • 프론트 엔드에서 쿠키로 각 가계부 필터 관리

    • 가계부가 n개일 때, n개의 쿠키가 생기게 된다.
    • 쿠키에는 유저ID, 가계부ID, 필터 정보를 들고 있어야 한다.

• 2번 사항을 도입하지 않을 때의 이점

  • 위와 같은 복잡한 상태 관리가 필요하지 않게 되고, 현재 들어가있는 가계부 하나의 상태만 관리하면 된다.