배운 점들 ㄱ. 테스트 자동화 경험 github actions, RTL, jest, lint 등을 활용한 테스트 자동화, 추후 배포 자동화나 슬랙 알림 등 다양한 곳에 활용할 수 있다. ㄴ. 성능 최적화 경험 크롬의 lighthouse, performance를 활용한 성능 측정 / 코드 스플릿, 텍스트 압축을 통한 로딩 성능 최적화 ㄷ. emotion, recoil 활용 아쉬운 점들 ㄱ. 렌더링 성능 매우 저조 특정 셀 속성, 값 변경시 다른 셀과 도구상자도 렌더링 되는등 관련 성능이 매우 저조하다. memo를 잘 활용하고 상태관리 구조를 잘 짰으면 훨씬 좋은 성능이 나왔을 것 같다. ㄴ. 버그 매우 많음 리팩토링하면서 복사 기능이 날아가는 등, 버그가 매우 많아졌다... 꼼꼼한 테스트 코드가 있었으면 ..

성능 측정 크롬의 lighthouse를 활용해서 성능 측정을 했다. 매우 성능이 안 좋게 나왔다. Opportuity 탭을 살펴보니 js파일이 너무 커서 로딩이 오래 걸리는 것을 알 수 있었다. webpack-bundle-analyzer를 통해 번들 크기를 보니 번들이 1개이고 용량이 매우 컸다. 1. 로딩 성능 최적화 - 코드 스플릿 엑셀 에디터는 페이지가 1개이기 때문에 페이지 별로는 코드 스플릿을 할 수 없다. 따라서 컴포넌트별로 코드 스플릿을 했다. // 기존 import { Header } from '@/layout' // 변경 const Header = lazy(() => import('@/layout').then(({ Header }) => ({ default: Header, })) ) dy..

Github Actions와 RTL, Jest로 만든 테스트코드를 이용해서 테스트 자동화를 해봤다. 테스트 코드 각 컴포넌트, 기능(features 디렉토리) 별로 테스트 코드를 작성했다. RTL의 user-event를 활용해서 사용자 행동기반 테스트코드를 만들었다. /// Functionbar.test.tsx describe('', () => { test('선택셀 좌표 input 렌더링한다.', () => { render() const coordInput = screen.getByTestId('coordInput') expect(coordInput).toBeInTheDocument() }) test('선택셀 좌표 input default값인 "A1"이 담겨있다', () => { render() cons..

시트별 상태관리 어려웠던 점 처음에는 여러 개의 시트를 고려하지 않고 시트가 1개인 엑셀 에디터를 제작했다. 초기 상태는 다음과 같다. cells(표 각 cell의 정보), historyInfo(작업 내역 스택), selectedArea(드래그한 cell영역), selectedCell(클릭하여 선택한 cell), copiedArea(복사한 영역) 해당 상태들을 context에 담아서 하위 컴포넌트에서 사용했다. 엑셀 에디터를 시트가 여러 개인 형태로 변경하면서 최대한 기존 구조를 유지하면서 시트 여러개 활용(ms excel처럼)하도록 변경하는 것이 어려웠다. 해결 각 시트별로 해당 상태를 저장해야 했는데, 최대한 기본 구조 수정을 하지 않으면서 변경하기 위해서 context위에 recoil을 뒀다. re..

1. 개요 이전 통계 자동화 페이지에서 통계 엑셀 파일 미리보기 기능을 개발했었다. 토이 프로젝트로 해당 기능을 좀 더 발전시켜서 엑셀 파일을 웹에서 편집할 수 있는 에디터를 제작해봤다. 2. 구조 type 관리 공통적으로 사용하는 type들은 루트 디렉토리의 types 디렉토리의 editor.d.ts에서 관리했다. // editor.d.ts declare module 'editor' { export interface IFile {/* 생략.. */} export interface ISheet {/* 생략.. */} /// 생략.. } 각 컴포넌트의 prop, return등의 타입 정보는 해당 컴포넌트 소스코드에서 관리했다. // ToggleButton.tsx interface ToggleButtonPr..