하루를 마무리 하기 전, 오늘 있었던 일들을 잔잔히 되짚어봅니다.
성공과 실패의 모든 요소에서 '배울 점'을 찾아내어 기록하고,
더 성장하는 내일의 나를 위해 'action plan'을 세웁니다.
엊그제, 아니 며칠 전부터 끙끙 싸매고 앓았던 새로고침 시 문제가 오늘 내로 해결될 기미가 보이지 않았고 결국 트레이너님께 도움을 요청했다.
나는 '새로고침'이라는 현상 자체에 매몰되어 있었는데 트레이너님과 이야기하면서 '현상' 자체에 집중할 것인가, 정확한 원인이 무엇인지를 파악하고 이를 분리해 낼것인가에 대해 고민하게 되었다.
사실 나 스스로는 '새로고침'이라는 현상에 매몰되어 있다고 생각하지 않았다.
'당연히 새로고침을 해서 문제가 발생했으니 새로고침 할 때 문제다~ 라고 하는 것 아닐까?' 라고 생각했는데...
결론적으론 refresh의 문제가 아니라 (1) useEffect의 특성으로 인한 순서싸움과 localStorage에 대한 잘못된 이해와 활용, (2) 잔액을 서버에서 받아오지 않고 프론트에서만 처리해서 발생하는 문제 두 가지로 나뉘게 되었다.
먼저 useEffect.
이번 디버깅을 통해 공식 문서를 허투루 읽어서는 안된다는 교훈을 얻었다.
한글 버전의 공식문서에 정확히 아래와 같이 언급되어 있다.
후반부에 집중해보면, 'effect를 렌더링 이후에 발생하는 것으로 생각하는 것이 더 쉬울 것입니다. React는 effect가 수행되는 시점에 이미 DOM이 업데이트되었음을 보장합니다.' 라고 쓰여있다.
즉, 나는 단순하게 fetch~ 정보들을 useEffect에 넣어두면 뭔가 다 fetch가 되어서 데이터를 뿌려주겠거니~ 하고 있었는데.
좀 더 정확히 이야기하면 effect는 돔이 업데이트되었음을 보장하기 때문에 렌더링 '이후'에 발생하는 것으로 이해하면 된다는 것이다.
accessToken을 저장하는 함수가 useEffect안에 들어있었고, 이 때문에 렌더링 되기 전에 accessToken의 유무 여부를 확인해야 하는 어떤 로직이 순서싸움에서 지게 되어 계속 새로고침 시 로그인이 튕겨나가는 현상이 발생한 것이다. (localStorage에 accessToken이 저장되어 있었음에도 불구하고...)
사실 이 부분은 지난주 강의에서 아샬님이 다뤘던 부분이다.
근데 강의를 들으면서도 정확히 이해가 되지 않아서 '이게 뭔 얘기지...' 하고 몇 번 따라치고 넘어갔던 부분인데. 엉뚱하게 여기에서 발목이 잡혔었다.
하지만 이렇게 과정 하나 하나를 console.log로 찍어보고, 실제로 useEffect 안에서와 다른 곳에서 console.log 내용들이 어떤 순서로 나타나는지를 눈으로 확인하니 제대로 이해가 됐다.
왜 그런 코드가 index.jsx 파일 안에 들어갈 수밖에 없었는지도 이제서야 이해가 되었고...
오히려 고생한게 좋은 경험이 된 격이다. 머리가 좀 아프고 시간도 많이 쓴게 좀 씁쓸하긴 하지만 ㅎㅎㅎ
잔액조회 역시 마찬가지였다.
내가 오해한 부분이 있었는데, 백엔드쪽에서 만든 API에 대해 반드시 프론트쪽에서 주소를 부여하고 접근을 해야만 사용할 수 있다는 이상한 생각에 사로잡혀서 이 부분을 계속 손놓고 있었다.
결국엔 우선 해보자 라는 마음으로, 따로 컨트롤러를 만들기엔 거창한 것 같아 login쪽에서 코드를 추가해줬는데 역시나 잘 된다. 애초에 잔액을 서버에서 받아오지 않은 것이 문제였기 때문에 그걸 받아와서 전체에서 뿌려주면 금방 해결될 문제였다.
결국은 해보는 것, 그리고 찬찬히 찾아가는 것만이 문제 해결 방법인 것 같다.
그런 의미에서 아직 마음의 큰 부담으로 남아있는 css와 테스트코드.
토요일은 이미 다 지나갔지만 내일까지는 적어도 css를 30% 이상 해보도록 하자. 다음주엔 하루정도라도 남기고 css와 테스트를 모두 메이크업 하고 마무리 공부를 좀 하고싶다. 하하. 소망사항...
남은 주말도 힘내보자!
