반응형
Overview - Material UI
Material UI is an open-source React component library that implements Google's Material Design. It's comprehensive and can be used in production out of the box.
mui.com
UI는 위 사이트에서 컴포넌트를 가져다 썼다.
원래 쌩으로 CSS 건드려서 만들어 보려고 했는데, 이쁘지도 않고 너무 시간이 많이 투입되었다.
디자인도 디자인인데 UI 라이브러리 사용여부에 따라 생산성 차이가 정말 크다는 걸 실감했다.
- 최초 접속 시 로그인 페이지를 노출한다.
- 계정이 없을 경우 회원가입을 할 수 있도록 한다.
※ 개선사항 - OAuth 2.0 구글/카카오 로그인 가능하도록 처리
- 5개의 입력 칸에 모두 입력을 해야 [회원가입] 버튼이 활성화된다.
※ 개선사항 - 이메일 인증 기능 추가, 입력 값 유효성 체크 처리
- 위에서 [회원가입] 버튼을 누르면 회원가입이 완료되었음을 전달하는 페이지로 이동한다.
- 즉시이동 버튼이 있지만 누르지 않더라도 5초 후 로그인 화면으로 이동한다.
사실 컨펌창으로 충분히 구현할 수 있지만 보기 좋은 떡이 먹기도 좋다고 그냥 좀 이쁘게 공들여 보고 싶었다.
- 로그인 시 대시보드를 기본 컨텐츠로 보여준다.
- 사이드바에는 프로젝트 관련 메뉴, 헤더 우측에는 사용자 관련 메뉴가 있다.
- 사이드바 메뉴에는 아직 개발된 거 하나 없다.
- 현재 헤더 우측의 메뉴 버튼을 누르면 나오는 워크스페이스 메뉴 화면을 개발 중이다.
- 워크스페이스가 없을 경우 생성을 유도한다.
- [워크스페이스 생성] 버튼을 누르면 나오는 화면.
※ 개선사항 - 최대 인원, 프로젝트 종류 등 도메인 공부 후 필요 메타 추가하기
- 페이지 접속 시 워크스페이스 목록 중 가장 첫 번째 값이 기본적으로 선택된다.
- 워크스페이스를 생성/편집/삭제할 수 있으며 아직 개발 안 되었지만 멤버를 추가할 수 있다.
- 선택된 워크스페이스의 멤버 목록을 보여주며 리더가 아닌 경우는 관리 컬럼의 버튼을 통해 리더 지정, 추방 처리할 수 있다.
※ 개선사항 - 우선순위를 지정할 수 있도록 워크스페이스 정렬 기능 개발
- 아직 멤버 추가를 못한다.
- 가입요청의 경우 리더가 멤버를 추가(가입요청)하면 해당 사용자에게 컨펌을 받거나 역으로 사용자가 워크스페이스를 찾아 가입 요청을 하도록 할 것이다. 그런데 해당 로직을 생각 못해서 가입요청을 관리하는 도메인을 개발하지 못했다.
- 마찬가지로 멤버 추가를 못해서 리더 지정, 추방 기능도 개발하지 못했다.
※ 개선사항 - 사용자 관리가 가능한 프로필 메뉴 화면 개발, 리더 행에는 관리 버튼 노출하지 않도록 처리
- 그런고로 다음은 사용자 관리가 가능한 프로필 메뉴를 개발할 예정이다.
마치며
처음엔 토이프로젝트 관련해서는 포스팅 안 하려고 했는데 사실 뭐 그렇게 대단한 내용도 아니고 숨길 필요 없다고 생각해서 그냥 올리려고 한다.
화면 개발하다 보면 요소 하나하나에 필요한 자잘한 기능이 너무 많이 보인다.
대부분 서버단이 아니라 프론트단에서 처리해야 하는 부분이 많은데, 리액트가 처음이라 너무 버벅대고 있다. 처음에 리액트 컴포넌트 분리를 안 하니까 문서마냥 엄청 길어져서 분리하는 데에도 시간 꽤 들었다. 처음부터 분리할 걸 싶다.
처음 프로젝트 시작할 땐 화면 개발 없이 REST API 서버만 개발할까 생각한 적이 있었다. 그런데 이번에 화면 개발하면서 눈으로 직접 데이터 흐름을 보고 필요한 데이터를 확인해야 서버단에서 어떻게 조회해야 하는 지를 확실히 알 수 있었고, 화면 개발이 생략할 순 없는 과정임을 알게 되었다. 리액트 재미는 있는데.. 서버단에서 구현하고 싶은 부분도 정말 많아서 생략할 수도 없고 답답한 느낌이 드는 건 어쩔 수 없다. 연휴나 주말 밖에 시간이 없다 보니 이런 부분이 너무 아쉽다. 😰
처음엔 userProvider 커스텀 훅을 만들어서 사용자 상태를 전역에서 관리했는데, 새로고침 하면 해당 정보가 사라져 버린다. null 참조 오류가 계속 발생해서 생각해 보니 프론트 단에서 API 요청할 때 굳이 이메일을 파라미터나 DTO에 포함할 필요 없이, 같이 전달되는 토큰에서 서버단이 이메일을 확인하면 된다. 그러면 더욱 Restful 하게 개발할 수 있다.
참고로 본인 서버에서는 스프링 시큐리티를 함께 사용하여 로그인 시점에 토큰의 사용자 정보는 SecurityContextHolder에 저장되고, 각 API에서 해당 객체를 참조하면 된다.
추후에는 엘라스틱 서치 검색엔진 도입하고 키바나로 시각화할 예정이다. 그 이후에는 채팅 웹소켓? 데몬 서버 만들어서 워크스페이스에서 멤버 간 소통이 가능하면 좋을 것 같다. 근데 이건 그냥 근거 없는 생각일 뿐이고 가능한지는 더 조사해봐야 한다.
이번 연휴에는 서버단 현재 개발된 부분만이라도 화면 개발 마치는 걸 목표로 하고 있는데 불가능할 것 같다. ㅠ
'개발 > 리액트' 카테고리의 다른 글
리액트 핵심만 훑어보자 #10 조건부 렌더링 (0) | 2025.03.07 |
---|---|
리액트에서 API 호출 URL을 환경 변수로 설정하자 (0) | 2025.02.23 |
리액트 핵심만 훑어보자 #9 이벤트 처리 (46) | 2024.11.24 |
리액트 핵심만 훑어보자 #8 훅 (45) | 2024.11.23 |
리액트 핵심만 훑어보자 #7 리액트 컴포넌트의 생명주기 (41) | 2024.11.17 |