이 글은 아래 링크의 내용을 바탕으로 작성되었습니다. https://medium.com/humanscape-tech/react에서-해보는-코드-스플리팅-code-splitting-56c9c7a1baa4 https://ui.toast.com/weekly-pick/ko_20180716 자바스크립트 코드 분할 자바스크립트 코드를 분할하는 방식에는 정말 여러가지가 있지만, 그 중 가장 간단하고 유용하다고 생각되는 방식을 적용해보겠습니다. 그것은 바로 동적 import + React.lazy 메서드 + React.Suspense 컴포넌트를 조합해서 사용하는 것입니다. 참고로 동적 import 를 사용하기 위해서는 @babel/plugin-syntax-dynamic-import 패키지가 필요하고 이를 바벨에 적용하..

이 글은 아래 링크의 내용을 바탕으로 작성되었습니다. https://jeonghwan-kim.github.io/series/2020/01/02/frontend-dev-env-webpack-intermediate.html 어플리케이션의 로딩 속도를 줄이는 가장 직관적인 방법은 HTML, CSS, Javascript 코드 사이즈 자체를 줄이는 것입니다. 그냥 코드를 짧게 작성하는 당연한(?) 방법도 있겠지만 일반적으로 웹팩 플러그인 설정을 통해 빌드 결과물이 기존 소스코드보다 용량이 적어지게 하는 방법을 사용할 수 있습니다. HTML 파일 축소 npm install --save-dev html-webpack-plugin or yarn add -D html-webpack-plugin const HtmlWebp..

프론트엔드 성능 측정 방법이 궁금하시다면 아래의 링크를 참고해주세요. https://codingmoondoll.tistory.com/entry/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94-Quick-Start-1 프론트엔드 성능 분석 Quick Start 개인적으로 생각하기에, 어떤 분석을 수행하느냐에 상관 없이, 가장 좋은 분석 방법은 직접 측정해보고, 데이터를 모아서 이를 바탕으로 논점과 결론을 이끌어내는 것입니다. 프론트엔드에서 codingmoondoll.tistory.com 이전 시간에는 성능을 분석해보고 어느 부분에서 성능상의 이슈가 있는지를 도출하는 일을 했습니다. 이제 그..

개인적으로 생각하기에, 어떤 분석을 수행하느냐에 상관 없이, 가장 좋은 분석 방법은 직접 측정해보고, 데이터를 모아서 이를 바탕으로 논점과 결론을 이끌어내는 것입니다. 프론트엔드에서 성능 최적화를 하는 방법도 마찬가지죠. 직접 지표와 기준을 결정하고 스스로 도구를 이용해서 현재 어플리케이션의 성능을 측정하는 것이 최선의 방법일 것입니다. 그러나 현실의 개발자들은 기능을 구현하고 여러 요구사항을 반영하느라 눈코 뜰새 없이 바쁜 경우가 많습니다. 그러니 최소의 시간을 들여 나의 웹 어플리케이션 성능을 측정해 보는 방법을 이번에 소개해드리겠습니다. 제목을 'Quick Start' 라고 지은 만큼, 깊은 내용을 다루기 보다는 '해야할 일' 자체에 집중해보겠습니다. 기준 정하기 - Web Vitals 성능 분석의..

이 글은 Kent C. Dodds 저자의 아래의 글을 바탕으로 작성되었습니다. useEffect vs useLayoutEffect useEffect vs useLayoutEffect The simple rules for when to use each. kentcdodds.com 리액트 훅들 중 useEffect 와 useLayoutEffect 의 기능은 매우 유사합니다. 하지만 분명하게 다른 use case 를 가지고 있죠. useEffect 사실 정말 대부분의 경우, 개발자들은 이 훅을 쓰게 될 것입니다. useEffect 는 컴포넌트의 렌더링이 모두 수행된 후 비동기적으로 동작하는 훅이며, 이를 통해 기존의 componentDidMount, componentDidUpdate, componentWill..

Type 과 Interface 는 매우 유사한 기능들을 가지고 있고, 실제로 대부분의 프로젝트에서 개발자는 둘 중 어느 것을 선택해서 사용해도 상관 없을 경우가 많습니다. interface 에서 사용할 수 있는 기능의 대부분은 type 에서도 사용 가능한 경우가 많기 때문입니다. 차이점 1 : 선언 후 타입 확장성 (출저 : https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#differences-between-type-aliases-and-interfaces) 하지만 그렇다고 해서 아예 둘의 차이가 전무한 것은 아닙니다. 둘의 가장 큰 차이점은 type 은 선언 시점에서 그 내용을 고칠 수 없는데 반해, interface 는 선언 후에..