전체 글

어떤 2개의 타입의 이름, 위치가 다르더라도 구조가 같다면 Typescript는 2개의 타입을 같은 타입으로 본다. (Duck typing) type A = { a: string } type B = { a: string } let a: A = {a: 'aa'} let b: B = {a: 'bb'} a = b // 가능 b = a // 가능 정리 Typescript는 컴파일 단계에서 타입 검사를 하는데 이때 Duck typing 방식을 사용한다. C#/java는 이름이 같은지까지 확인하는 nominal typing 방식을 사용한다.

TS 버전업 TS 버전을 기존 4.4.2 -> 5.2.2로 올렸다. 버전업시에 기존 yarn berry 3.3.0과 호환이 되지 않아 yarn berry도 3.6.3으로 올렸다. 다른 의존성도 해당 버전에 맞게 업데이트했다. TS 5.0 이상은 데코레이터, 파라미터 const 타입, Enum을 Union 타입과 호환 등 여러가지 변화가 있다. 이 참에 해당 기능들을 좀 활용해보면 좋을 것 같다. dev:msw 명령어 추가 개발시에 msw 구동이 필요할 때와 아닐 때(api 찌를 백엔드가 있는 경우)가 있다. 그런 경우에 활용하기 위해 기존 dev 명령어를 dev(msw X), dev:msw (msw O)로 나누었다. .env로 msw 구동 여부``를 환경여부를 주입해서 코드상에서 활용하도록 했다. ///..

배운 점들 ㄱ. 테스트 자동화 경험 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..

백엔드 서버 요청 처리 (MSW 활용) 실제로 서버에 요청하는 E2E 테스트를 할 수도 있지만, 백엔드보다 프론트엔드가 먼저 개발이 들어가거나 하는 경우나, 프론트만 분리해서 테스트 하고 싶은 경우에는 MSW를 활용할 수 있다. 서버 요청시 MSW가 가로채고 모의 응답을 보내준다. MSW 초기 설정 테스트에서 요청들을 mock server가 가로채도록 설정해준다. // src/mocks/server.js import { setupServer } from 'msw/node' import { handlers } from './handlers' // This configures a Service Worker with the given request handlers. export c..