투자 관리 서비스의 관리자 기능 구현
2022/09/20 ~ 2022/09/25
http://d12r37ezbodeiz.cloudfront.net
test id: test@test.com
password: test
$ git clone https://github.com/wanted-pre-onboarding-frontend-6/pre-onboarding-assignment-week-4-1-team-5-B.git$ yarn add$ yarn start |
 |
 |
 |
 |
| 김성용(팀장) | 성민규 | 임상빈 | 이재하 | 박세리 |
| FE Developer | FE Developer | FE Developer | FE Developer | FE Developer |
open
수정
✔️ 사용자 목록
- 표기되어야 하는 정보
- 고객명(name) : 가운데 글자 마스킹 필요, 두글자일 경우 성을 제외한 이름 마스킹 처리, 4글자 이상일 경우 마스킹 처리 후 앞뒤 한글자만 표기
- 고객명을 누를 경우 사용자 상세화면으로 이동합니다.
- 보유중인 계좌수(account_count) : (해당 API 호출 후 데이터를 정제하여 표기)
- 이메일 주소 (email)
- 주민등록상 성별코드 (gender_origin)
- 생년월일 (yyyy-mm-dd) (birth_date)
- 휴대폰 번호 (가운데 4자리
***로 마스킹 필요) (phone_number) - 최근로그인 (last_login)
- 혜택 수신 동의 여부 (해당 API 호출 후 데이터를 정제하여 표기) (allow_marketing_push)
- 활성화 여부 (해당 API 호출 후 데이터를 정제하여 표기) (is_active)
- 가입일 (created_at)
- 고객명(name) : 가운데 글자 마스킹 필요, 두글자일 경우 성을 제외한 이름 마스킹 처리, 4글자 이상일 경우 마스킹 처리 후 앞뒤 한글자만 표기
- 구현되어야 하는 기능
- 목록에서는 활성화 여부, 임직원 계좌 여부를 필터링 할 수 있어야 합니다.
- 리스트 페이지에서는 검색이 가능해야 합니다.
json-server의 Full-text Search API 를 사용하여 구현합니다.- 예시 : GET http://localhost:3000/users?q=South
- 페이지네이션이 되어야 합니다.
json-server의 Paginate API 를 사용하여 구현합니다.- 예시 : GET http://localhost:3000/users?\_page=1&\_limit=20
- 임의로 신규 사용자를 추가할 수 있어야 합니다.
- 잘못 생성한 사용자를 삭제할 수 있어야 합니다.
- 개명을 한 사용자를 위해 사용자명을 변경할 수 있어야 합니다.
✔️ 계좌 목록
- 표기되어야 하는 정보
- 고객명(user_name) : 고객ID 를 참조하여 실제 이름으로 보여져야 합니다.
- 고객명을 누를 경우 사용자 상세화면으로 이동합니다.
- 브로커명(broker_name) : 예시) OO증권,
brokers.json를 참조하여 실제 이름으로 보여져야 합니다. - 계좌번호(number) : 앞 뒤 각각 두글자를 제외하고 나머지는 글자수에 맞게
*글자로 마스킹 처리가 필요합니다. - 계좌상태(status) : 예시) 운용중,
accountStatus.json를 참조하여 실제 이름으로 보여져야 합니다. - 계좌명(name) : 계좌명입니다.
- 평가금액(assets) : 예시) 123,123,123
- 입금금액(payments) : 예시) 123,123,123
- 계좌활성화여부(is_active) : 계좌 활성화 여부
- 계좌개설일(created_at) :
- 고객명(user_name) : 고객ID 를 참조하여 실제 이름으로 보여져야 합니다.
- 구현되어야 하는 기능
- 목록에서는 브로커명, 계좌 활성화 여부, 계좌 상태를 필터링 할 수 있어야 합니다.
- 리스트 페이지에서는 검색이 가능해야 합니다.
json-server의 Full-text Search API 를 사용하여 구현합니다.- 예시 : GET http://localhost:3000/accounts?q=South
- 페이지네이션이 되어야 합니다.
json-server의 Paginate API 를 사용하여 구현합니다.- 예시 : GET http://localhost:3000/accounts?_page=2&_limit=20
✔️ 상세
- 각 사용자, 계좌의 상세 페이지는 획득 가능한 대부분의 정보를 표시해주시면 됩니다.
✔️ 조건
- Sider 메뉴에서는 현재 보고 있는 화면에 해당하는 메뉴가 하이라이트 되어야 합니다.
- 새로고침을 해도 로그인 상태가 유지되어야 하며, 상태에 따라 기존에 머무르던 화면이 그대로 보여야 합니다.
- 계좌 리스트에서 계좌번호를 누르면 계좌상세 화면으로 이동합니다.
- 계좌 리스트에서 사용자 이름을 누르면 사용자 상세로 이동합니다.
- 사용자 상세에서 사용자의 계좌목록이 보여야 합니다.
- 계좌 목록에서 각 계좌 상태별로 필터링이 가능해야 합니다.
- 수익률이 플러스인 계좌의 총자산 금액은 빨간색, 원금과 동일한 경우 검정색, 마이너스일 경우 파란색으로 보여줘야 합니다.
- 계좌 목록에서 broker_id 에 해당하는 실제 브로커명 (OO투자증권) 이 보여야 합니다.
A팀, B팀으로 나누어 개발 후 각 팀의 코드를 비교했습니다.
✔️ A팀 REPO
redux-toolkit과 thunk, react query와 recoil 중 어떤 기술 스택을 사용할지 고민했습니다. redux-toolkit을 사용하면 보일러 템플릿을 많이 작성해야 한다는 단점을 해결 할 수 있으나, redux의 store는 서버의 복사본일 가능성이 있으며, 최신 상태로 관리되지 않을 수 있습니다. 그러나 react-query는 client, server가 같은 정보를 가지고 있는지 관리할 수 있습니다. stale과 fresh 상태를 관리할 수 있는 기능을 지원하기 때문에, 가지고 있는 정보가 stale한 상태가 되었을 때, 업데이트 요청을 할 수 있습니다. 이 외에도 직접 만들어야 했던 기능들을 react query에서 지원해주기 때문에 손쉽게 개발할 수 있습니다.
그러나 react-query는 redux와 같은 전역 상태 관리 라이브러리가 아니고, 비동기 작업을 손 쉽게 할 수 있도록 도와주는 라이브러리이기 때문에 전역 상태를 관리할 수 있는 라이브러리를 같이 사용해야 합니다. 이의 대안으로 recoil을 주로 많이 사용합니다. recoil은 상대적으로 배우기 쉽고, 아주 간단하게 전역 상태를 관리할 수 있기 때문에 저희 팀 또한 recoil를 채택했습니다.
<Route>, <Routes>와 같은 element를 작성하는 것보다 객체로 route를 관리하는 것이 더 가독성이 좋다고 생각 되었습니다. 그리고 path를 상수화 시키면 유지 보수에도 좋고, 오타의 위험을 줄일 수 있어 상수로 관리했습니다.