Facts
최근 기존 express server 를 통해 SSR 로 구현된 legacy code 를
react-router-dom 을 사용해 CSR 로 변경하는 업무를 맡게 되었다.
업무를 진행하기 위해 기존에 express 를 통해 해주던 일을 clinet 로 넘겨야 했다.
legacy code 에서 redux state 를 초기화 하여 client 에 보내고 client 에서
server 를 통해 받은 store 를 이용해서 store 를 다시 초기화 해서 사용하고 있었다.
그래서 일단 server 에서 redux 초기화 하는 부분을 list-up 하면서 client 로 이동시켰다.
이후 개발 편의성을 위해 기존 webpack watch mode 를 webpack dev server 로 변경하여 test 를 해보았는데
재귀함수 처럼 계속 처음 화면을 다시 출력하는 현상을 확인했다.
일단 react 문제인지 확인해 보았는데 아얘 resource 를 다시 불러오는 것으로 보아 용의선상에서 제외했다.
이후 webpack-dev-server 문제인지 확인해 보았지만 별다른 혐의점을 찾을 수 없었다.
전회사에서 비슷한 ? 실수를 한경험이 있어 혹시 location API 가 어딘가 걸려있어 url 이 / 로 이동하는 게 아닐 까 생각했다.
찾아보니 역시나 try - catch 의 catch 에서 window.location.reload 를 호출하고 있었다.
전회사에서도 데이터를 받는데 실패하면 catch 에서 url 주소를 직접 변경하는 부분을 넣었다가 큰일이 난 경우가 있었는데
legacy-code 에서 비슷한 부분을 발견했다..
결론적으로 catch 에서 url 를 변경한다던지 하면 무한 재로딩이 발생할 경우가 있어 catch 문에서 location 을 조작하는 것은 안하는게 맞는 것 같다.
code 넣은 사람이야 알지 모르는 사람입장에서는 resource 가 reload 되면 debug 하기 굉장히 힘들어진다..
팀원들과 내용공유해서 비슷한 부분이 있으면 무조건 빼야 겠다.
Findings
- window.location.reload()
새로고침 버튼 처럼 resource 를 다시 불러옴 - try... catch ... finally
- catch 의 경우 try 에서 error 가 발생할 경우 실행
- finally 의 경우 error 가 발생하던 안하던 try 또는 catch 이후 실행
Feelings
- 협업을 위해 git, jira, slack 잘 쓰는것도 중요하지만 애초에 debug 하기 어려운 code, 가독성 ㅈ 박은 code, test code 없는 code 이런걸 배제 하는게 가장 중요한 것 같다.
