트러블 슈팅 노트 : (Polymer) B2C 샘플 페이지에서 view1페이지가 아닌 다른 페이지에서 새로고침 후 view1로 접근시 DOM이 제대로 잡히지 않음

현상

1. 페이지 3개 (view1, view2, worklist)가 있고 전체 페이지의 레이아웃을 설정해주는 my-app가 있다.
2. view2, worklist에서 새로고침을 하면 view1 페이지에 접근시 아무것도 나오지 않는다.
   

   

view1의 this를 참조하면 이렇게 잡혀야 한다. (정상적으로 동작 할 때)

실제로는 이렇게 잡힌다. (shadow DOM이 활성화되어 있지 않음)

다른 페이지에서는 안 그런데 유독 view1 페이지에서만 그렇게 된다.

그렇다고 레이아웃을 관장하는 <my-app>에서 view1 페이지를 특별히 다른 방법으로 접근하는 것도 아님. WTF?

천천히 생각해보자..천천히.. Shadow DOM이 안잡힌다는 것은 무엇을 의미하는가?

시도 1.

개발자 도구에서 vinimum 플러그인에서 같이 오류가 나길래 설마 하는 마음에 해당 플러그인을 비활성화시키고 다시 시도

• 실패

시도 2.

혹시 사용자 정보 페이지가 맨 위에 있어서 뭔가 영향을 받나 싶었서 사용자 정보 & 판독 목록 페이지 위치 교체

• 실패

view2 페이지에서 새로고침을 하고, view1로 접근하면 오류가 나고

worklist 페이지로 접근하면 튕기지 않는다.

두 페이지를 비교해보자. 분명 API 요청하기 전에 다른 처리를 해 줄것이다..

새로 고침을 하는 순간 무엇인가가...Shadow DOM이 아니게 되어버리는건가?

다른 페이지에서 새로고침을 한 후 개발자도구로 my-view1을 보니까 헉.. shadow dom이 잡혀져 있지 않음.

시도 3.

왠지 view1이 아닌 my-app.html의 문제일 것 같아서 확인을 해 보니 

view1에서 아무것도 하지 않아도 다른 페이지에서 새로고침만 하면 그냥 view1의 Shadow DOM 자체가 형성이 안되는 것을 확인 할 수 있었음. 뭐야 이거?

이전의 커밋 히스토리를 추적하여 어느 시점부터 이런 문제가 발생하였는지를 확인하였음

결국 문제의 원인이 되는 코드를 찾아냄

새로고침을 할 때에도 로그인한 유저의 변화를 observer가 감지하여 loginUserChanged 함수를 실행시키고, 여기서 라우팅의 path와 실제 보고 있는 page가 불일치하게 되는 것이 문제의 원인이었다.

• login/logut시에만 해당 메소드가 작동할 줄 알았는데 예상치 못했던 상황이었다.
• 로그인/로그아웃을 할 때 뷰를 이동시킬 목적으로 작성하였음
  • 사용자가 존재하면 view1로 이동
  • 사용자가 존재하지 않으면 main으로 이동
• 문제 발생 상황 : view2에서 새로고침을 할 때 해당 메소드가 실행되어 버리므로, view2 페이지를 보고 있지만 실제로 라우팅의 path는 view1로 지정된다.

이제 보고 있는 page와 route.path가 일치하지 않으면 왜 동작을 하지 않았는지 확인해본다.

각 페이지 변경점마다 로그를 찍어서 확인해봤다.

정상적인 경우

비정상적인 경우 (worklist페이지에서 새로고침)

정상적인 경우는 페이지를 1번만 불러오고, route.path와 페이지도 일치한다.

그러나 비정상적인 경우는 view1을 불러왔다가 다시 worklist를 불러오는 것을 확인할 수 있다.

게다가 route.path와 페이지는 일치해야하는데 페이지는 worklist, route.path는 view1로 잡혀있음.

이것이 구체적으로 왜 내부적으로 Shadow DOM Tree를 만들지 못하는지 등은 Polymer의 내부 동작과 연관되어 있다고 생각하여 더는 조사하지 않았다.

• 아마 한번 불러온 페이지는 캐싱을 하거나.. 뭐 그런 문제가 아닐까? 기회가 되면 찾아봐야지.

해결

변경 전

 

변경 후 (새로고침시 해당 메소드가 불릴 경우의 대응)

느낀점

• 안된다고 무작정 이것저것 해보는 것 보다는 천천히 고민을 해보며 원인을 유추하는 것이 실력 향상에 도움이 되는 것 같다.
• 어느 정도 시간을 들여도 원인을 찾지 못할 때에는 이전의 코드로 롤백하여 안되는 코드를 확인하는 것이 좋다.
• 버그 해결에서 끝이 아니라, 문제가 발생하게 된 원인을 할 수 있는한 최대한 파악을 해야 다음번에 동일한 실수를 발생시키지 않는다.
• 프로그래머는 사람이므로 당연히 버그를 발생시킨다. 두 번도 실수할 수 있다. 하지만 똑같은 버그를 세 번 발생시켰다면 실수가 아닌 실력이므로 반성해야 한다.