프로젝트 자체의 분량은 훨씬 많아졌다. 다만 내가 맡은 부분의 분량이 조금 미미할뿐.로그인 회원가입은 금방할 수 있었지만, 이메일 중복확인 기능은 백엔드에서 완성될때까지 기다리느라 많이 늘어졌었다.
중복확인까지 제대로 된 이후에는, 버그와의 싸움이 시작되었다.
아직 자동로그인의 로직을 완벽하게 이해하지 못했는데, 중간중간 눈에띄는 버그가 좀 있다. 몇가지 살펴보았던 것을 기록해둔다. 일단, 각 창의 버튼마다 입력조건에 부합하지 않으면 버튼을 누를 수 없게 조건을 걸어두었다.
회원가입 로그인 과정부터 찬찬히 뜯어보면,
일단 회원가입 창에서 일반회원 가입, 공인중개사 가입 버튼 하단에 이미 아이디가 있다는 문구가 있다.
일반회원가입 부분 세부오류
일반 회원은
아이디로 쓸 이메일을 입력하고,
비밀번호를 입력한다. (특수문자, 영대소문자, 숫자 8자리이상 30자리이하)
두 인풋창 다 형식에 맞게 쓰지 않으면 하단에 오류메시지를 띄우고 인풋창 테두리 색상도 빨간색으로 바꾼다.
맞게 입력이 되면 원래대로 돌아오고, 오류메세지 대신 알맞은 형식이라는 메시지를 띄운다.
알맞게 입력된 내용에 따라 버튼이 활성화 되고, 시작하기 버튼을 누를수 있다.
시작하기 버튼을 누르면, 중복된 아이디가 없을 경우 무난하게 가입이 되고, 가입과 동시에 로그인 처리가 된다.
이게 일반 회원 가입 & 로그인의 과정이다.
이 과정에서 이메일을 입력하고 비밀번호를 입력하면, 자동으로 이메일의 아이디부분을 닉네임으로 처리해서 데이터베이스로 넘기게 된다.
인풋창에 알맞게 쓴 내용을 백스페이스로 지우면 다시 오류메시지가 뜨는데,
여기서 발견한 버그는 인풋창을 깨끗하게 비웠음에도 불구하고, 콘솔에 한글자가 남아있어서 오류메시지가 뜬다는 것이다.
이를 해결하기 위해 고민해보았다.
- 인풋창이 비어있는 것을 인지하게 하는 방법,
- 한글자가 남아있을때는 오류메시지를 띄우지 않는 방법
지금 나의 수준으로는 두번째 방법이 적합해 보이는데,
한 글자만 써졌을때 아무것도 메시지를 띄우지 않아야 될 것 같았다.
물론 버튼의 활성화는 용납하면 안되겠지만, 적어도 오류메시지는 두글자 이상 입력하면서 발생하는 것으로 해야 하지 않을까…
더 자연스러운 해결방법을 찾고 싶다.
거기다가 블로그에서 보고 쓴 정규식에서 8자리부터 30자리까지 입력한다고 설정해두었지만, 컨트롤이 제대로 되지 않는거 같다.
영어소문자로 5글자, 대문자 1글자, 특수문자 1글자, 숫자 1글자를 쓰면 8개를 충족하기 때문에 버튼이 활성화 되어야 하는데, setState가 잘 이루어지지 않아서 띄어쓰기를 하거나 한글자를 더적어야 활성화가 된다.
그러니까 한 박자가 느린셈이다.
전에 이메일 쓰는 쪽에서 이러한 문제가 발생해서 onBlur를 써서 해결했다고 생각했는데, 비밀번호쪽에서 이렇게 문제가 발생을 하니 다시 혼란이...
이미 함수에 많은 State를 물려두었다. 더 많아지면 훨씬 느려지지 않을까 걱정이 될 정도로...
이 버그에 대한 해결법을 생각해보면, 인풋창을 제대로 인식하게 하는 방법밖에 없을거 같다. 아직 해결되지 않아서 이번주에 고민을 해보아야 겠다.
공인중개사 회원가입 부분 세부 오류
공인중개사 회원 가입 부분에서 이메일 중복확인을 별도의 API로 만들어서 연결해야 했다.
공인중개사 회원가입 시
첫페이지는 일반회원가입과 동일하다. 버그도 동일하다.
일반회원가입 페이지에 있던 '시작하기' 버튼 대신에 '다음' 버튼이 있는데, 이 버튼을 누를 경우 먼저 이메일 중복검사를 시행한다.
중복 되는 것이 없으면 사용할 수 있는 이메일이라는 메시지의 alert 창이 뜬다.
Alert 창을 닫고, 다시 다음버튼을 눌러야 다음페이지로 넘어간다.
공인중개사 회원가입에서 다음페이지가 있는 이유는, 자격증 같은 인증 사진을 필요로 하기 때문이다. 그래서 회원가입정보를 다 입력했다고 하더라도, 바로 회원가입이 되는 것이 아니라 관리자의 승인이 필요하다.
공인중개사 회원가입 부분에서 발견한 문제점은
유저의 노동(?)이 불필요하게 많다는 것이다.
다음버튼을 눌렀을때, 이메일중복확인이 되면 오류가 있을시에만 수정을 하면 되는데, 오류가 없는 경우에도 창은 자동으로 넘어가질 않는다.
이부분을 해결하기 위해서는 중복되지 않았을때는 사용가능하다는 멘트 말고 그냥 바로 넘어가는 로직을 구현해야하나 싶다. 중복이 되었을때만 오류메시지를 띄워주면 될것 같은데, 체크해봐야겠다.
로그인은 마찬가지로 인풋창이 조금 늦게 인식된다는 버그가 있다.
한개만 개선이 되면 다른 페이지에도 고르게 적용할수 있을 것 같다.
자동로그인 로직이 너무 길어지니 자신감도 떨어지는 와중에 3주차 중간발표 날이 다가왔었다.
기술면접 시에 물어보는 질문들을 중간발표에서 듣게 된다고 했다.
회원가입, 로그인 기능은 생략해도 괜찮은 부분이어서 다른 메인기능을 중점적으로 설명하는데, 같은 프로젝트를 하고 있지만 난이도 차이가 커서 불안한 마음이 들었다.
분명히 같이 시작했는데, 구현할수 있는 로직의 범위가 이토록 차이가 난다면 나의 공부법에 문제가 있다는 생각도 들었다.
트러블 슈팅에 대한 세션과 사전질문을 받아봤을때 들었던 기분도 동일했다. 이걸 잘 헤쳐가서 밥값하는 개발자가 될수 있을까?
어떤 문제를 고민하고 해결하는 과정에서 시간이 너무 많이 든다면 바른 길로 가고 있는게 아닐텐데… 정말 나를 뜯어 고치고 싶은데 속도가 나지 않는거 같아서 참 답답하다.
하루가 똑같이 24시간이고 주당 100시간씩 쏟아붓는건 모든 사람들이 하고 있는 일이라 그 속에서 어떻게든 살아남으려면, 능률을 올려야 한다는 결론이 나왔다.
4기통 엔진으로 6기통 엔진을 따라잡으려면 더 꾸준히 오래 달리면 될텐데, 문제는 시간의 제약이 있다면 그 누가 와도 절대로 결과가 달라지지 않는다는 것이다.
이제 정말 얼마 남지 않았는데, 포트폴리오를 준비하고 면접을 준비해서 단기간에 취업에 성공할 수 있을까 하는 우려가 밀려와서 집중력이 흐트러졌다. 장기간 취업을 못한다면 나는 개발자 직군에서 멀어질 가능성도 있겠다. 이렇게 시간을 내어서 공부 할 수 있는 기회는 지금뿐이라는 생각.. 아니 이미 조금 지나버렸다. 다른 대안을 모색해놓지 않으면 금방 길바닥에 나앉을지도..ㅎ 목구멍이 포도청이라 먹고 사는 것과 병행해야 할텐데..그때도 놓치지 않고 공부를 할 수 있을지 조금 걱정이 되었다.
남은 3주동안 프로젝트에서 맡은 바 역할은 최선을 다해 수행을 하고, 어떻게든 취업을 해야 하니 할 수 있는데까진 해봐야 겠다. 팀동료들의 코드를 보고 나도 조각기능을 연습해보아야 겠다는 생각이 들어서 조금씩 해보고 있는데, 어렵다.
중간발표 직전에 멘토님에게 사전질문을 받을수 있었는데, 허가 찔린 느낌이었다.
Styled component를 사용한 이유와 장단점,
redux대신 react query와 recoil을 쓴 이유.. 리덕스가 불편했던 점?
브라우저가 화면을 렌더링 하는 과정…
이 세 가지의 질문을 받았었는데,
개인적인 답변은 다음과 같다.
1. Styled component를 사용한 이유
CSS 파일을 별도로 분리하지 않고 한 컴포넌트 안에 작성가능하기 때문에 사용함.
전체적인 적용이 필요한 것만 CSS 파일을 만들어서 사용중.
CSS 문법으로 스타일을 지정할 수 있어서 어렵지않게 사용할 수 있었음.
프로젝트 전체기간내에서 구현해야할 디자인과 기능들을 고려했을때 빨리 작성해서 빨리 테스트 할수 있는 CSS-in-JS 방식이 저희에게는 유용하다는 판단.
장점
컴포넌트 단위로 이름을 붙여서 적용할 수 있어서 외부와 완전히 격리시킬수 있고, 해당 컴포넌트 내부에서만 유효하도록 해서 다른 작업들과 충돌할 일이 없었음.
JavaScript 환경에서 CSS문법을 사용해 스타일을 지정해 줄 수 있어서 편하고, 작은 요소들까지도 자유롭게 구현이 가능해서 디자인적으로 구현하기 힘든 부분은 없었음.
단점
다만, 수정사항을 컴포넌트마다 세세하게 다 고쳐줘야 할때도 있는데 그럴때 보면 코드 가독성이 많이 떨어짐.
아직은 쉽게 찾아 갈 수 있는 상황이지만, 컴포넌트의 숫자가 훨씬 많아지면 찾아 바꾸기에
어려움을 겪을듯.
그려야 할 것이 많은 화면을 그리는 속도가 조금 느린 듯. 페이지마다 속도가 다름.
2. 리덕스를 사용하면서 불편했던 점, react query와 recoil을 쓰면서는 괜찮은지 여부
리덕스는 초기에 설정해야 하는 부분을 통으로 암기해야 했다.
액션함수와 리듀서를 쓰기 위한 공부방식은 암기가 가장 효율적이었고, 리코일과 리액트 쿼리와 비교를 한다면, 암기 해야할 분량의 차이가 크다는 것이 단적인 비교.
비동기 서버통신을 위해 사용했던 미들웨어인 Redux Thunk는 액션함수에 도달하기 전에 원하는 작업이 있을땐 유용할지도 모르지만, 초보자가 사용하기에 콜백함수를 제어하기도 쉽지 않고, 암기할 것 도 많아 기능 구현 자체에 어려움을 느꼈음.
리액트 쿼리와 리코일을 쓰면서는 작성해야할 코드 양이 확연히 줄어서 데이터를 주고 받는 과정에 대한 이해가 리덕스를 쓸 때보다 나아짐. 리코일은 리액트 useState와 같은 hook의 사용 방법만 이해하면, 리코일을 사용할 수 있어서 비교적 쉽게 접근할 수 있었음.
3. 브라우저가 화면을 렌더링 하는 과정
클라이언트 서버에서 ip정보를 담은 도메인을 통해 실제 주소를 DNS 서버로 요청하면, DNS 서버는 index.html, app.js를 넣어 응답해온다. 리액트의 경우에는 index.html이 한개다.
요청하고 응답하는 과정에서 얻어온 데이터들은 서버에 webpack의 형태로 저장되어 있다가
Index.html에 실려 오는 것이다.
서버로부터 받아온 파일들로 render tree를 구성하고 이를 바탕으로 실제 화면에 렌더링 하게 된다.
리액트는 Props, state, 부모컴포넌트의 렌더링 등의 상황에서 리렌더링이 발생하고 화면을 새롭게 그린다는 특징이 있다. 이때 가상의 DOM을 이용하기 때문에 화면이 깜빡거리지 않고 빠르게 DOM을 새로 그린다.
여기서 정확하게 알지 못하는 개념은 webpack, render tree 이다.
webpack은 자바스크립트의 모듈번들러라고 한단다. 자바스크립트로 된 꾸러미들을 관리하기 위한 패키지로 이해했는데 아직 명쾌한 설명을 하진 못하겠다.
Render tree는 트리형태로 작성한 코드들의 도표 같은거라고 이해했다. 이걸… 기술면접때 이렇게 이야기 하면 안될거 같다 …
프론트엔드 기술면접시 받는 질문들과 답을 미리 좀 공부해야 한다.
밤을 샐수록 머리가 안돌아가는 느낌이라 만신창이가 된 느낌.
물론, 제대로 이해하지 못하면 답변은 저런식으로 나온다는게 걱정이다 정말…
