Week5_day03 스크럼

스크럼

• 이준희
  • 끝나고 바로 그냥 정신을 잃어버리고... 잠들었습니다. 5주 프로젝트 동안 가장 오래 잔 듯...
• 이연정
  • 늦게 끝나서 이력서 쓰고 잤습니다..!
• 이은솔
  • 개발의 진척이 있지는 않지만 이번주는 배우는게 많은 것 같습니다.
  • 늦게 끝나서 놀다가 이력서 쓰고 잤다.
• 박은식
  • 늦게 끝나서 이력서 쓰고 놀다 잤다.
• 위정훈
  • 발표를 어떻게 할까 5분정도 생각하다가 잠들었습니다

---

발표주제

 발표 준비는 최대한 여러분들이 5주 동안 어떤 경험을 했는지. 
 기술역량관점에서 도움이 된 부분이 무엇인지를 잘 설명할 수 있는 형태로

가제1: 그러면 이 방법 어떤가요? - 그러면을 제시해나가는 개발기 5주 동안 개발을 진행하며 집중해서 고민하였던 사항을 말씀드리고자 합니다.

• 키워드; 사용자 편의성? custom hook, 성능/퍼포먼스 향상을 위한 노력, 무엇을 배웠나

• 개발시 고민사항들 / (이전 - 개선사항)

  • 소개, 주제 설명 30초 / github, notion 설명, 배포주소 채팅창에 남기기, 실행 결과는 gif
  • 차이 전체 (비교하기 / undo / redo)(localstorage) > 성능 개선?
  • 체크박스의 역할에 대한 처리방식 > UX
    • 있고 없고.. 이렇게 차이가 크다고?!
  • Redux를 통한 상태관리 > Redux, custom hook에서 custom hook의 호출 (redux 상태(전역 상태)를 deps로 가진 useEffect 가 있다면 추천 하지 않는다..!) - React

발표 흐름...

• 발표 7분 Q&A 8분

• 소개, 주제 설명 30초 (github, notion 설명, 배포주소 채팅창에 남기기, 실행 결과는 gif)

  • 팀 소개
  • 프로젝트 개요
  • 기술 스택 간단히
  • 간단히 어떤 주제에 대해 앞으로 말할지 ======== 30초

• 고민한 부분 (2분 * 3)

  • 히스토리 상태 관리하기. 차이 전체 (비교하기 / undo / redo)(localstorage)

    • 우리 프로젝트에서의 히스토리 + undo / redo의 의미 설명 간단히

    • undo / redo / 히스토리 어떻게 구현할까?

      • 차이를 반영
      • 전체 스타일을 반영

    • 지도에 스타일을 적용하는 방식에는 '어떤 요소'를 '어떻게' '변경할 것이다'가 필요한데 (시각화가 중요할 것 같아요. 이해를 돕기 위해서)

      • 어떤요소: 바뀌어야할 요소, 어떻게: 바뀌어야하는 결과 값, 변경하다: mapbox API 를 통해 앞의 '어떤 요소'를 '어떻게' 바꿀 것이다가 적용
      • 편집 상태 데이터 저장 형태의 차이(한 스타일 속성을 바꾸는 편집 |테마나, 가져오기 등의 전체 편집)
      • 데이터 처리의 차이 (undo/redo 하나의 스타일만 필요 | 전체 스타일이 필요)
      • 특정 히스토리(로그)를 클릭했을때(비교하기 기능) 해당 로그에 대한 스타일 적용을 해주어야합니다. 이때 적용되는 방식이 한 속성의 스타일만 바꿀때는 '시각적 자료 '>'의 연속' 으로 변경된 속성 부분이 적용되어야하고, 테마적용, import, reset등은 전 카테고리의 스타일이 변경되어야한다. 따라서 스타일이 변경될때 저장되어야하는 데이터는 각단계에서 변화되는 부분과 각 단계에서의 전 카테고리의 스타일 속성값들 모두 필요하다.
      • 이 두가지 데이터를 가지고 좀 더 효율적인 작업을 진행할 수 있는 방법을 찾고자하였다.

    • 따라서 위와 같은 스타일 적용 작업은 API 요청(비용이 높은 맵렌더링)을 필요로 하여 최대한 횟수를 줄일 필요가 있음.

    • 차이만을 저장할 경우 연산량이 많아지고, 전체 스타일만을 저장할 경우 API 요청양이 많아진다.

    • 그러한 이유로 redux에서 스타일 관련하여 상태를 관리하는 종류를 나눔

      • 변경할 당시의 스타일 요소와 해당 스타일 요소에 대한 결과, 변경한 후의 모든 카테고리에 대한 스타일
      • undo / redo와 같은 단계별 스타일 적용만으로도 구현가능한 부분에 대하여 변경할 당시의 스타일 요소만 사용. 비교하기와 같이 새로운 스타일의 지도 자체를 만들어내야할때 전체스타일 부분을 사용.

    • 위의 설명에 대한 시각자료 필요

    • 히스토리 상태 유지?

      • 처음에는 상태변경시 무조건적으로 localstorage에 반영. 하지만 local storage io 관련 비용이 큼.
      • 따라서 새로고침 또는 창을 닫을 시 localStorage에 history를 저장하도록 변경

  • custom hook 관련 시행착오...(?)

    • 우리의 디자인 패턴?
      • Container-presentational => 각 컴포넌트마다 custom Hook을 두는 방향으로 대체
    • Custom Hook을 재사용하고자하는 시도 => custom hook안의 custom hook
      • 코드 예시 (useMarkerFeature, useHistoryFeature => 관련 로직을 모아두자..!)
    • Redux가 관리하는 전역 상태가 custom hook안의 useEffect deps에 포함되어있는 경우
    • 리팩토링 과정에서 useEffect안의 불필요한 사이드 이펙트 중복 처리 발견
    • 뭐지...?
    • 다른 hook에서 불리는 과정에서 추가적으로 실행
    • 만약 custom안에 deps로 redux 상태를 가지고 있는 useEffect를 사용하려면 hook을 좀 더 신경써서 나누어야하는구나...!

  • 후보: UI / UX 고민, 현재 색상정보를 사용자가 인식가능하게 할수는 없을까?에 대한 고민