개발일기

패턴으로 알아보는 전역 상태 라이브러리

원문은 Github에서 확인하실 수 있습니다. 본 글은 상태 관리 라이브러리의 패턴 집중하여, 개별 라이브러리의 자세한 사용 방법 등의 내용은 생략하겠습니다. Prop DrillingReact와 같은 컴포넌트 기반 라이브러리/프레임워크에서 부모 컴포넌트가 자식 컴포넌트로 데이터를 전달하는데, 이때 여러 컴포넌트를 거치며 전달되는 패턴입니다. Prop Drilling이 왜 문제가 돼?거쳐가는 컴포넌트 계층이 많아지면 데이터가 어디서 왔는지, 어떻게 사용되는지 알기 힘들게 됩니다.또한, 데이터가 거쳐가는 컴포넌트들이 불필요하게 props를 전달하면서 코드 복잡성을 증가시키고 컴포넌트 재사용을 떨어뜨리게 됩니다. 그럼 어떻게 해결할 수 있어?해결 방법은 크게 세 가지가 있는데요.Context APICustom..

대상 독자자바스크립트 이벤트 루프에 대한 지식이 있는 분렉시컬 스코프와 실행 컨텍스트에 대한 지식이 있는 분호이스팅에 대한 지식이 있는 분    실행 컨텍스트 (Execution Context)Lexical Environment에 대해 알아보기에 앞서, 자바스크립트의 실행은 실행 컨텍스트(Execution Context)에 의해서 일어납니다. 실행 컨텍스트란 실행할 코드에 제공할 환경 정보들을 모아놓은 객체입니다. 즉, 코드를 실행하기 위해 필요한 정보들이 들어가 있는 공간입니다. 이 공간들을 콜 스택에 쌓아 올리면서 자바스크립트를 실행합니다. 실행 컨텍스트를 구성할 수 있는 방법으로는 전역 공간, eval, 함수 등이 있습니다. 우리가 흔히 실행 컨텍스트를 구성하는 방법으로 대표적으로는 함수를 실행하는..

3차례의 QA와 5회의 유저 테스트(UT)를 진행하며, 자잘한 버그를 해결하고 테스트 유저로부터 피드백을 수집했습니다.  테스트 과정 중 "글 수정 기능이 있으면 좋겠다"는 피드백을 받아 수정 기능을 구현하기로 결정했습니다. 하지만 새로운 풀이 작성 페이지와 풀이 수정 페이지를 같은 MissionSubmitPage로 재사용하고자 했기에, 이를 어떻게 설계할지에 대해 고민이 들었습니다. 그래서 일단 흐름도를 그려보기로 했습니다.글 작성 페이지를 (1) 새로운 글을 작성하기 위해 방문하는 경우와, (2) 수정하기 위해 방문하는 경우를 나누기 위해 url에 solutionId 파라미터를 추가했습니다. 페이지 로드 시 파라미터를 확인하여, 데이터가 존재하면 서버에서 기존 데이터를 가져와 수정 작업으로 간주합니다..

모던 리액트 Deep Dive를 학습하고 정리한 글입니다. 5.1 상태 관리가 필요한 이유상태 : 어떠한 의미를 지닌 값. 어플리케이션의 시나리오에 따라 지속적으로 변경될 수 있는 값.상태로 분류될 수 있는 것들UI : 다크/라이트 모드, 라디오, input 등URL : 브라우저에서 관리되고 있는 상태 값form : 로딩 중인지, 제출되었는지, 접근이 불가능한지, 값이 유효한지 모두 상태로 관리됨서버에서 가져온 값 : 대표적으로 API 요청상태 관리의 역사Flux 패턴의 등장MVC 패턴은 모델과 뷰가 많아지면 복잡도 증가이렇게 MVC 패턴을 적용한 어플리케이션이 비대해지고 상태도 많아짐에 따라 상태를 추적하기 어려워 짐페이스북은 이 문제를 양방향 데이터 바인딩을 원인으로 봄컨트롤러에서 모델로는 단방향이지..

본 글은 2024.11.13에 마지막으로 수정되었습니다.  Devel Up 서비스에는 '위로 가기 버튼'이 있습니다. 아래 사진과 같은 버튼인데요, 글이 길어지는 경우 사용자 경험을 향상시키기 위해 스크롤을 최상단으로 끌어올릴 수 있게 해주는 버튼입니다.      이 버튼은 페이지 스크롤에 상관 없이 항상 position: fixed로 화면에 고정되어 있었습니다. 하지만 스크롤이 최상단에 있는 경우에도 버튼이 존재하는 것이 어색하다는 사용자 피드백이 있었습니다. 따라서 이 버튼을 스크롤이 특정 지점 아래에 있을 때만 보이도록 구현하기로 했습니다.  여기서 든 의문점이 있었습니다. 1. 사용자의 스크롤 위치를 항상 구하고 있어야 되는가?2. 스크롤 위치를 항상 구하고 있어야 한다면, 이벤트의 콜백 함수를 ..

본 글은 2024.11.05에 마지막으로 수정되었습니다.    CSR와 SSR CSR와 SSR은 웹 어플리케이션을 렌더링 하는 대표적인 방법들이다. 본 글에서는 CSR와 SSR의 동작 원리와 이를 비교하며 장단점을 작성하려 한다.   CSR ( Client Side Rendering) CSR은 브라우저에서 거의 모든 작업이 이루어지는 렌더링 방식이다. React의 경우 기본 HTML에 컴포넌트를 갈아 끼우는 SPA로 동작하기 때문에, 서버로부터 처음 받아오는 html 파일은 아주 간단한 HTML 상태다.             이 기본 HTML 파일에는 태그만 있을 뿐, 서버에서 받아오는 데이터는 없는 상태다.브라우저는 HTML 파싱을 통해 파일을 위에서부터 순차적으로 읽어나가다     React    ..

본 글은 2024.11.06에 마지막으로 수정되었습니다.  1편과 이어집니다.  웹 사이트의 성능을 높여보자 (1) (요청 크기 줄이기, 필요한 것만 요청하기)개선 전후 성능 측정 결과   요청 크기 줄이기 1. 소스 코드 줄이기  Home 페이지에서 불러오는 스크립트 번들 크기가 951KB였다. 웹 페이지의 권장 번들 사이즈는 250KB 미만으로, 번들 사이즈의cho-sim-developer.tistory.com    같은 건 매번 새로 요청하지 않기 1. CDN 설정 1-1. CDN 캐시 설정 npm run build를 통해 생성된 정적 파일을 S3에 업로드 한 뒤 CDN을 통해 접근 가능하도록 했다.CDN의 캐시는 CachingOptimized를 적용! 새롭게 변할 데이터가 없을 것이라 판단하여 최..

성능 개선 중 S3와 CDN에 배포를 진행하며 캐시를 설정했다. CDN과 S3의 데이터에 새롭게 변할 데이터가 거의 없을 것이라 판단하여 모두 캐싱 기간을 1년으로 설정해 두었다. 여기서 궁금한 점이 생겼는데, S3에도 캐시 기간 설정을 할 수 있고 CDN에서도 캐시 설정을 할 수 있다. 그렇다면 각 캐싱이 어디에 적용되는지 헷갈렸다😵‍💫 정리하자면, 1. S3의 max-age : 브라우저가 캐시를 저장하는 시간이때, CDN의 최소 TTL < max-age < 최대 TTL인 경우 : CDN의 캐싱 시간은 max-agemax-age < 최소 TTL인 경우 : CDN의 캐싱 시간은 최소 TTL최대 TTL < max-age인 경우 : CDN의 캐싱 시간은 최대 TTL2. S3의 s-maxage : CDN이 캐..

개선 전후 성능 측정 결과   요청 크기 줄이기 1. 소스 코드 줄이기  Home 페이지에서 불러오는 스크립트 번들 크기가 951KB였다. 웹 페이지의 권장 번들 사이즈는 250KB 미만으로, 번들 사이즈의 용량 개선이 필요했다.  1-1. minify & uglify // webpack.config.js optimization: { minimize: true, }  Webpack v5부터는 production mode로 배포 시 기본적으로 압축과 난독화가 진행된다. TerserWebpackPlugin이 내장되어 있기 때문에, 자동으로 최적화가 이루어진다. minify & uglify 이전minify & uglify 이후압축률951KB216KB약 77%   그렇다면 development로 배포하..

4차 스프린트에서는 프로젝트의 목표였던 "개발 환경 개선"에 집중할 수 있었습니다. 저희 팀의 프론트엔드 인원이 다른 팀에 비해 한 명이 적다 보니 개발 환경의 효율화와 생산성 향상이 꼭 필요했습니다. 그래서 프로젝트를 하면서 제가 어떤 부분에 기여할 수 있을지 고민하다, 개발 환경을 개선시켜 생산성을 높여보자는 목표를 정했습니다.  1. 자동 배포 (CD) 개발 환경을 개선하기 위한 방법 중 첫 번째로는 자동 배포(CD)에 도전했습니다. 프론트엔드의 CI는 이미 구축되어 있었지만, CD는 구축되지 않은 상태였습니다. 그래서 배포 환경에서 테스트를 하려면 pem 키를 가진 크루에게 부탁해서, 우분투에 접속한 후 수동으로 배포를 해야 했습니다. 환경 변수가 추가되거나 변경 사항이 생길 때에도 우분투 CLI..