[cloer chat] client pug에서 react로 전환

 

 

가볍게 pug로 front end를 개발하다 결국 react로 전환하게 되었다.

 

 

---

pug에서 react로

 react를 몇 번 써봤고 state, props에는 익숙하지만 context API, routing은 개념만 알고 사용해 본적이 몇 번 없어 조금 더 써보고 나중에 프로젝트할 때 react를 써야지 하는 마음에 pug로 개발을 시작했었습니다. 아무래도 html, css, vanillaJS에 익숙한 저에게는 pug는 손발처럼 편했습니다. 하지만 pug로 개발하던 중 이럴 바에 찾아보면서 react로 하자 라는 생각이 들어 react로 전환하게 되었습니다.

 

 

---

pug에서 느낀 불편함

 pug에서 layout과 include를 적절하게 사용하면 react처럼 컴포넌트 단위 개발을 할 수 있습니다. 단순한 화면을 그리는데에는 큰 불편함은 없고 오히려 react보다 pug가 더 직관적이고 코드도 짧았던 것 같습니다. pug의 불편함은 data fetching에서 느꼈습니다. 정확히 말하면 pug의 불편함보다는 react의 편함 인 것 같습니다. 또 서버와 클라이언트가 독립적이지 않아 구조가 복잡해졌고 테스트를 하려 해도 서버와 클라이언트를 모두 손대야 테스트가 가능했습니다.

 

 회원가입 페이지를 구현하던 중 react로 전환해야 겠다고 생각이 들었습니다. 상황은 이렇습니다. 

1. 회원가입을 위해 client에서 email, nickname, password를 post로 서버로 전송
2. email, nickname, password 형식, 길이 확인
3. 형식, 길이가 요구 사항과 다를 경우 회원가입 창에 관련 메세지 출력 후 다시 회원 가입
4. email, nickname이 중복되지 않는지 DB에서 확인
5. 중복된다면 회원가입 창에 관련 메세지 출력 후 다시 회원 가입
6. 회원가입이 정상적으로 완료된다면 로그인 창으로 redirect

 과정 3, 5에서 회원가입 창에 메세지를 넣은 후 다시 출력할 때 불편함이 있었습니다. 사실 간단하게 해결할 수 있습니다. 각 분기점에  res.locals.message에 원하는 메시지를 넣고 res.render('signUp')을 하면 간단히 해결되는 부분입니다.

socket.io/src/routes/auth/authController.js

진행하다가 만 부분이라 email과 password 형식을 확인하는 부분이 없으니 그점 감안하고 봐주시기 바랍니다. res.redirect 부분에 res.locals.message='이메일 형식이 잘못됐습니다.'; res.render('signUp');로 처리하면 간단합니다. 하지만 저는 signUp을 렌더링 하는 부분을 하나의 함수로 처리하고 싶었습니다. 만약 개발을 하다가 res.locals.message를 res.locals.warningMessage로 변경하게 되면 흩어져 있는 res.locals.message를 모두 찾아 고쳐줘야 하기 때문이고 논리적으로도 같은 기능을 하는 부분을 여러 번 작성하고 싶지 않았니다. 그래서 res.render('signUp')을 담당하는 /signup으로 redirect 해줬습니다. 여기서 문제가 발생합니다. redirect는 client에 요청을 보내고 redirect를 응답으로 받은 client가 다시 서버로 요청을 보냅니다. http는 stateless이기에 redirect를 하게 되면 두 번째 요청을 받은 get('/signup')은 message를 알지 못합니다. 

1. 서버: post('/auth/signup') -> email확인 -> 문제 발생 -> 문제 메세지 생성 -> redirect('/signup') 응답
2. 클라: redirect 하라는 응답 받음 -> get('/signup') 요청 보냄
3. 서버: get('/signup') -> 문제 메세지 없음 -> render('signUp') 메시지 출력 안됨

 redirect를 시키는 부분에서 메세지를 생성하는데 render는 다음 요청에서 이루어지기에 메시지가 표시되지 않습니다. 그래서 생각한 방법이 서버에서 redirect응답을 보낼 때 cookie에 메시지를 넣어 보내고 client에서 redirect시 그 메세지 쿠키를 다시 서버로 보내면 서버는 쿠키에서 메시지를 뽑아 render 하고 쿠키를 지우는 방식입니다. 즉 flash cookie로 http 프로토콜의 stateless를 해결할 계획이었습니다. 여기서 급 현타가 왔습니다. 이거 react로 그냥 json api 주고받으면 간단할 거 같은데... 하는 생각이 들어 react로 전환하기로 결심했습니다. 또 나중에 websocket 프로토콜로 채팅방을 만들 때 document.createElement로 하나하나 DOM조작할 생각 하니 공부도 할 겸 react로 하는 게 더 빠르겠다 싶었습니다.

 

 

---

 

react로 전환 후

 처음에도 말씀 드렸다 시피 처음에 바로 react를 사용하지 않고 pug를 사용한 이유는 프로젝트가 간단하게 끝날 줄 알았고 간단한 프로젝트에는 비교적 익숙한 pug를 사용하는 게 더 빠르다고 생각했습니다. 사용 경험이 적은 react의 route와 context api 때문에 react를 사용하지 않았는데 막상 써보니 공식문서에 설명도 잘 나와있고 사용법이 크게 어렵진 않았습니다. 무엇보다 json api 통신을 하니 백엔드 코드가 깔끔해졌고 따로 테스트를 하며 개발할 수 있어 생산성도 올라갔습니다.

더미 데이터를 이용한 독립적으로 개발

vs code의 rest extension을 이용한 서버 테스트

깔끔해진 서버

 

---

 

정리

 react로 전환한 이유를 정리하면 서버와 클라이언트 독립성 때문이었습니다. pug로 개발하게 되면 클라이언트와 서버가 섞여있고 코드가 난잡해서 정리하기가 쉽지 않았습니다. react로 전환하고 json으로 데이터를 주고받다보니 json의 형식을 맞춰놓으면 독립적으로 개발하기 쉬웠습니다. 서버는 vs code의 rest extension 혹은 postman으로 테스트하고 react는 json으로 더미 데이터를 만들고 테스트하고 나중에 연결해주는 식으로 개발하는 것이 훨씬 쉬웠습니다. 제목은 react로 전환이지만 서버 얘기만 한 것 같네요. 

 

한 줄 요약 

react로 바꾸고 나니 서버 클라이언트 독립 개발적으로 개발이 편해졌고 막상 해보니 route, context api도 별거 없었다.