# 네트워킹 데이 발표 시나리오

## intro

안녕
스타일 맵 어드민 툴 팀의 위정훈입니다

### 팀원 소개

- 번호순으로..(이름)
- 백엔드 없이 모두 FE
- (특별히 분야 나누지 않고 VSCode 라이브쉐어 활용한 협업한 경우가 많았음)

### 프로젝트 개요

- 사용자가 지도의 테마를 선택하거나 요소의 색상, 굵기 등 스타일을 조정할 수 있는 스타일 편집툴
- 사용자 작업 내용을 로그로 저장해 비교하기/undo/redo 가능
- url/json 형식 내보내기, 가져오기 가능
- 주요 기술 스택으로 mapbox API, TS, React-Redux, Emotion.js 활용

//스택나열하며 붙이는 말이 라이브러리를 최대한 사용하지 않고 구현하고자했다는말 들어가면 좋을것 같아용

## 프로젝트를 진행하며 고민했던 내용들

### 히스토리를 어떻게 관리할 것인가

히스토리란?
- 사용자가 작업 내용들을 로그로 저장해 히스토리 목록에서 확인 가능
- 히스토리 목록에서 특정 로그를 선택할 경우 비교하기 가능
- undo-redo 기능 활용해 현재 상태 전후 이동 가능 + 이동되는 시점을 히스토리창에서 확인가능
// 히스토리 설명할 때 예를 드는 것이 좋을 것 같아요.(7p)

이때 필요한 데이터는
- 특정 시점에서 변경된 특정 스타일
- 특정 시점 전체 스타일

히스토리 관리 방식
- Redux
- 두 데이터 중 하나만 관리한다면 각각의 장단점
- 특정 스타일만 저장하는 경우
- 장점
- 단점
- 전체 스타일 저장하는 경우
- 장점
- 단점

저희의 결론은
- 둘 다 저장해서 연산/렌더링 비용을 줄이자
- 다만 저장 비용은 조금더 늘어날 수 있다
- 다양한 클라이언트의 상황을 고려해봤을 때
- 저장 공간이 조금더 추가되는 것은 크게 문제 되지 않지만
- 렌더링 관련 연산 비용은 전반적인 성능에 영향이 클 것이라는 판단

예시; 히스토리 관련 Redux 타입을 다음과 같이 정의
// 히스토리 상태 두 개를 말할 때 좀 더 구체적으로 말하면 좋을 것 같아요 (10p)

### 사용자가 새로고침을 하거나 재접속하는 경우?

또 한가지 히스토리 관련 이슈는

로컬 스토리지를 활용해 기존 작업 내용을 자동 저장하자
- 초기 매번 사용자 작업이 있을 때마다 === redux history가 업데이트될 때마다 로컬스토리지 작업
- 이 경우 I/O에 필요한 시간/비용이 상대적으로 많아짐
- 화면을 떠날 때 이벤트를 걸어서 로컬 스토리지에 저장하는 방식으로 변경
// 서버가 별도로 없다는 부분은 언급해주면 좋을 것 같아요

### Custom Hooks 사용 시행착오

프로젝트 초반 디자인 패턴에 대한 고민에서 출발
- 전형적인 Container-Presentational 패턴 적용을 시도
- 컴포넌트 depth가 늘어나면서
- 파일구조를 한번에 알아보기 힘들고
- 네이밍도 너무 길어지고
- 유지보수하기 어려워짐
- (과연 이렇게 하는게 맞나하는 의문이)
- 복잡도가 크게 늘어나는 듯..
- container 대신 custom hook을 별도로 분리해 이용하는 방식으로 변경

패턴을 변경하면서 hook B에서 hook A를 부르게 되는 경우가 있음
- hook A의 function A를 컴포넌트에서 직접 사용하는 것이 아니라
- 컴포넌트에서 활용하는 hook B에서 필요해서 가져오는데
- 컴포넌트를 거쳐서 넘겨주는 게 아니라 hook B에서 hook A를 직접 호출

그러면서 가져온 hook의 useEffect 내부 함수가 중복/여러 번 실행되는 문제를 발견
- `console.log(map)`을 했을 때 한번만 나오는 것을 기대하고 있는데,
- null일 때 2번, map이 로딩됐을 때 2번 찍히는 모습

// custom Hook 문제 예시 설명을 할 때 해당 코드를 같이 보여주면 좋을 것 같아요

원인은
- 해당 useEffect가 redux가 관리하는 전역 상태를 의존하고 있었고
- 이 hook을 여러 곳에서 import/호출하면서 중복 실행되고 있던 것

그래서
- 관심사에 따라 해당하는 hook들을 분리; redux 사용하는 hooks와 그렇지 않은 utils
- => 필요한 곳에서만 useEffect 등 hook이 실행되도록 변경해서 해결

(정리하면..)

## 결론

뭘 배웠는가..???
- hook을 사용할 경우 관심사 분리 관점에서 정교하게 나누는 것이 중요하다는 것을 깨닫게 되었습니다

감사합니다. 이상으로 발표를 마치고 질의응답을 진행하겠습니다.
많은 질문 부탁드립니다!

---

# 예상질문 리스트

## 전반

- 프로젝트 재미있었는지?
- 프로젝트를 통해 개인적으로 느낀점?
- 이 프로젝트를 통해서 이전보다 나아진 점이 있다면?

- 디자인 패턴 바꾸고 얼마나 개선이 되었는지? 바꾼과정에 대해 좀더 자세히 설명해준다면?
- 구글 스타일 맵에 비해서 어떤 점을 개선하려고 노력했는지?
- 주 사용자 층이 누구인지? 그 사람들이 썼을 때 정말 좋은 효과적인 툴이 될 수 있다고 생각하는지? 효용 관점에서
- 비즈니스 관점에서, 잘 팔릴 것 같은 서비스인지?
- 가장 어려웠던 부분
- 지도 개발 데이터에 대한 이해
- 복잡한 상태 관리

## UI/UX

- UI/UX에 대한 고민해봤는지?
- 어떤 부분이 개선이 되었는지?

## 테스트

- 테스트 코드 써봤는지? no..

## 퍼포먼스

- 렌더링 비용이 비싸다고 했는데 어떻게 아는지? 측정해봤는지?
- 들어가는 용량이 꽤 큰데, indexDB말고 localStorage를 사용한 이유?
- 새로고침 / 나갈 때만 로컬스토리지에 저장하는데, 그 과정에서 데이터가 유실될 경우는?
- web worker를 사용하지 않은 이유?

## 기타사항
- 채팅창에서 데모 url 드리기 => 프로젝트 개요 설명하면서 한번 언급할게요
- 눈치싸움 hackMD 필요함!
- 괜찮은 질문 slido에 등록해놓기

## 우리가 할 질문
- 왜 서버가 없나?
- 타겟층?

### 보완점?
크게보면 undo와 redo에서는 하나의 변경사항만 필요?
우리가 뭘 했다는 것을 보여주는 것에는 애매?

- 프로젝트 개요 수정; ppt도 수정
- 맵박스 api를 어떻게 활용했는지 - 스타일링 하는데만 사용, 레이어는 저희가 직접 분류
- 히스토리 상태 2가지 활용; 변경되는 상태만 저장하거나 전체를 저장하거나

## 멘토님께 드릴 말

@신재경 @이현수 @임병철
먼저 지난 주 금요일 일정에 혼선을 드린 것에 대하여 다시 한 번 사죄의 말씀 드립니다.
지난 5주간 멘토링해주셔서 정말 감사드립니다. 생각지 못한 부분들을 지도해주신 덕분에 방향을 다잡아가며 프로젝트를 진행해나갈 수 있었습니다. 좋은 개발자가 될 수 있도록 앞으로도 최선을 다하겠습니다!
내일 있을 데모 발표는 11:30~11:45 에
https://zoom.us/j/99081103164?pwd=QVZLWlNnMXJKUFJBUlpaRlFNZm1SQT09 에서 진행됩니다~ 그럼 내일 뵙겠습니다. 좋은 주말 되세요~ 😍