상태관리, SSR
#5 2019. 12. 16 - 2019. 12. 22
생활
전세자금대출을 준비하느라 은행업무에 많은 시간을 보내고 있다. 회사 이자 지원 대출을 받고 마이너스 통장을 옮겨타고, 영혼까지 끌어모아 최종적으로 얼마를 대출받으면 될지 결정했다. 이번주에 서류 마무리하고 몇번 더 방문하면 이제 정말 끝나지 않을까~ 하고 기대해본다.
회사
요즘 스토어에 대한 고민이 많다. 상태관리패턴에 대해 다시 생각해보고있다. 현재는 각 컴포넌트가 초기화 되는 시점에 주로 API를 호출하여 스스로를 초기화하고 있는데, 이 접근이 잘못된 것은 아니였나 하는 생각을 하고 있다. 외부세상에 API를 호출하고 상태를 초기화 하는 관심은 전부 스토어가 가져갔어야 하지 않나. 컴포넌트가 이 관심을 가져감으로 인해서 많은 사이드이펙트가 생기고 있다. 특히 SPA이 SPA스럽게 동작하게 하는 부분에 관련된..
API의 응답구조에 맞춰 스토어를 가져가다 보니 스토어가 복잡해졌다. 각각의 스토어가 마구 얽혀져 복잡도가 많이 늘어났다. API 중엔 레거시도 많다 보니 직관적이지 않은 속성도 많고, API 응답간 도메인의 인터페이스도 일치되지 않는다. 스토어도 도메인 관점으로, API 응답과 상이한 인터페이스는 API 클라이언트에서 맞춰주고 더 나아가서는 API도 좀 더 도메인관점으로 떨어져야 하지 않을까 하는 생각을 자주 하는 요즈음, 그래서 다들 그래프큐엘 그래프큐엘 하나 보다.
카페는 전부 클라이언트 사이드 렌더링을 한다. 사실 서버사이드 렌더링에 대한 필요성을 잘 못느끼고 있었다.
요즘 한가지 문제를 겪고 있는데 클라이언트 사이드 렌더링을 하다보니, index.html을 받고 첫 js을 로드하다 실패했을 경우 이를 추적하기가 굉장히 난감하다. 크래시 수집을 위한 도구들도 아직 초기화되기 전이고, 힌트가 될 만한 유저 정보도 아직 초기화되기 전이다.
이 문제를 어떻게 풀어야 하나. 청크에서 크래시수집도구를 분리해서 헤더에 초기화를 해야하나. 마지막으로 성공한 유저 정보를 추적할 수 있을 만한 키를 스토리지에 넣어두어야 하나. 첫 페이지는 서버사이드 렌더링을 해서 내려주어야하나. 고민이 깊어진다.
스터디
오브젝트 스터디를 시작하였다. 객체지향의 사실과 오해를 읽을 때도 느꼈지만, 조영호님은 글을 참 잘쓰시는것 같다.
