Facts
- 지하철 노선도 역 추가/수정/삭제를 할 때 상태 값을 변경하도록 구현했다.(5시간)
- 역 조회를 해서 화면에 렌더링하는 방법에 대해서 토론했다.(2시간 이상)
Feelings & Findings
지하철 노선도 역 추가/수정/삭제를 할 때 상태 값을 변경하도록 구현했다.
일단 어제 stations를 배열이 아닌 객체로 가지고 있었는데, 이것을 배열로 변경했다. 서버에서 전달해주는 역 정보가 배열이기 때문이다. 이렇게 바꾸는 데에는 5분도 걸리지 않았다.
그 후 역을 수정/삭제할 때 상태 값도 함께 업데이트가 되도록 구현했다. 상태 값을 업데이트 할 때(지하철 이름을 변경했을 때) 불변성을 유지한 채로 변경을 해보려고 시도했다가 코드가 너무 복잡해진 것 같아서 포기했다.
밥 먹으러 갈 때 다른 크루에게 물어보니까 JSON.parse(JSON.stringify(value))로 쉽게 깊은 복사를 할 수 있다고 한다. 이것에 대해 알고는 있었지만 너무 야매(?)인 것 같아서 사용하지 않았는데 누구나 알고 있는 정보라면 오히려 가독성이 더 좋을 수 있겠다는 생각이 들었다.
기존에 station class에서 stations의 상태 값을 가지고 있었는데, 노선에 추가된 역은 삭제할 수 없다의 조건을 맞추기 위해 그냥 UserDataManager라는 class를 만들어서 사용자의 데이터를 모두 관리하도록 했다.
이렇게 변경하는 과정도 1시간 정도 걸렸던 것 같다.
아, UserDataManager class는 싱글턴으로 구현을 했는데, 아무 곳에서나 쓰일 수 있기 때문에 항상 인스턴스가 같아야 한다고 생각해서 싱글턴으로 구현을 했다. props로 넘겨줄 수도 있지만 의존성을 제거해보고 싶었다.(사실 이렇게 해도 의존성이 제거되는 것인지 잘 모르겠다.)
엄청 순조롭게 진행이 되었다고 생각하지만 5시간 동안 이것밖에 구현하지 못한 이유가 궁금하다. 집중을 하지 않고 많이 쉬었던 것 같다.
역 조회를 해서 화면에 렌더링하는 방법에 대해서 토론했다.
역을 조회하면 사용자가 가진 모든 역이 배열로 넘어오게 되는데, 난 화면의 렌더링과 api 요청을 최소화하고 싶었다.
렌더링을 최소화하고 싶었던 이유는 데이터가 많아졌을 때를 고려해서 10000개의 데이터가 있다고 할 때, 역 조회를 누를 때마다 렌더링이 다시 일어난다면 느려질 것이라는 생각이 들었기 때문이다. 또한 10000개의 데이터를 innerHTML에 할당하기 위해 배열을 돌면서 템플릿을 만들텐데, 매번 10000개의 템플릿을 만드는 것이 너무 좋지 않다고 생각했다. 물론 10000개는 너무 과장이고... 실제로는 100개 정도 사용할 것 같긴 하다.
api 요청을 최소화하고 싶었던 이유는 api를 요청할 때 서버와 통신을 해야 하고, 이것은 큰 비용이라고 생각했기 때문이다. localStorage에 접근할 때도 fileIO가 발생해서 최소화하는 것이 좋다고 했었는데, 정확하게는 모르겠지만 api 요청은 localStorage보다 더 큰 비용이 발생할 것 같았기 때문이다. 지금 글을 쓰면서 느껴진 것은 정확한 이유도 모르고 느낌대로 코딩을 했던 것 같다.
api 요청을 최소화하기 위해서 처음에 한번만 사용자의 데이터를 받아오고, 그 이후에는 역을 추가/삭제/수정할 때만 api 요청으로 데이터를 넘겨주고, 상태 값을 업데이트 해주면서 화면에 렌더링하는 식으로 구현하고 싶었다.
즉, 역 목록 조회는 단 한번만 발생하는 것이다.
더 나아가서 렌더링을 최소화하기 위해서 한번 역 목록 조회를 한 뒤에 받은 역 이름을 템플릿에 할당해서 완성된 템플릿을 가지고 싶었다. 라우팅을 할 때마다 배열을 돌면서 템플릿을 그리고 innerHTML으로 넣어주는 것이 아닌 맨 처음에 한번만 템플릿을 만들고, 그것을 참조하면서 추가/삭제/수정을 하면 될 것 같다는 생각이었다.
하지만 우리가 만든 템플릿은 string이고, 이 데이터 자체는 변하질 않았다. 클로저도 사용해봤지만 역이 업데이트 되었을 때 그 당시에는 역이 업데이트 된 상태로 렌더링이 되지만 다시 역 목록을 클릭하면 업데이트되지 않은 것을 볼 수 있었다. 이유는 단순하다. 템플릿에서 초기에 역 목록을 넣어서 만들어주고, 그 템플릿을 업데이트 하지 않았기 때문이다.
아무리 생각해도 이 템플릿을 동적으로 업데이트하는 것은 좋지 않은 것 같았다. 두 번씩 일을 해야 하기 때문이다. 그래서 나의 고집을 꺾고, 내일은 api 요청을 최소화하는 방식으로 구현을 해볼 것 같다. 이것도 페어와 얘기를 해봐야 한다.
그래도 DOMParser도 사용해보고, 좋은 기회였다고 생각한다.
Plans
- 지하철 노선도 미션 노선 추가/삭제/수정까지 구현하기
- 데일리 미팅 조 회식 준비하기
