코드노트

현재 개인프로젝트를 리팩토링...? 아니 마이그레이션을 하고 있다. 처음에 React를 사용하여 작업을 했었지만 Next.js를 사용하여 프로젝트를 진행중이다. 이번 프로젝트를 진행하면서 Optimistic UI를 적용한 방법을 정리해보려고 한다. Optimistic UI - 사용자 요청을 서버에서 처리되기전 성공할 것을 가정하여 성공한 결과를 미리 보여주는 것이다. 사용자가 API요청을 보내게되면 서버에 요청을 하고 값을 받아서 변경된 값을 보여주어야하는데 그 값이 변하는게 오래걸린다면 사용자 경험에 있어서 좋지 않은 경험을 받게 된다. UI 시각적으로 우선 보여주고 그 뒤에 백그라운드에서 실제 작업이 실행된다. 그럼 아무곳에서나 사용해도 될까? - 아니다. 사용자에게 즉각적으로 피드백이 중요한 상황에..

LocalStorage, sessionStorage는 사용해봤지만 CacheStorage는 사용해볼 경험이 없었다. 현재 원티드 프리온보딩 인턴십에 참여하면서 매주 과제를 하고 있는데 4주차 과제에서 라이브러리 없이 API호출별로 로컬에 캐싱을 구현하는게 구현 목표중에 있었다. 검색을 할때마다 검색어에 맞는 요청URL별로 응답값을 캐싱하여야 한다. 지금까지 여러 프로젝트를 하면서 axios, react-query를 사용하면서 캐싱이 되도록 사용했었는데 라이브러리 없이...? 방법을 찾던 중 CacheStorage를 사용하여서 캐싱시키는 방법을 사용하기로 했다. 여기서 알고 넘어가야하는 것 HTTP 캐싱 - 이전에 가져온 리소스들을 재사용함으로써 네트워크 트래픽을 줄여 리소스를 보여주는데 필요한 시간을 줄..

이번 프로젝트에서 Next.js를 사용하기로 했다. Next를 사용하기로 한 이유는?- 현재 프로젝트는 생각보다 규모가 크다. 페이지도 많다. 간편하게 사용할 수 있는 next 라우팅을 사용하기로 했다. - SEO 최적화, 프론트엔드에서 중요하게 작용하는! 메타데이터를 쉽게 설정할 수 있고, 페이지별로 지정할 수 있기 때문에 안쓸이유가 없었다. - 리액트세계에만 있었던 사람이라면 Next세계로 들어오는 순간 다양한 렌더링 방식에서도 감탄을 하게 되는거 같다. 초기에 긴 로딩시간이 해결되지 않았다면 정적 파일을 제공하여 사이트의 성능도 높이고 로딩 속도도 높일 수 있다. - 프레임워크임에도 React 기반으로 어려움없이 사용할 수 있다. 그외 등등... 아무튼! 이번 글에 주제인 React-Query를 사..

Static Routing - 정적 라우팅- 정해진 폴더명에 맡게 path값이 결정app ㄴ 폴더명 ㄴ page.tsx // 페이지 명으로 폴더안에 page이름으로 만든다. ㄴ layout.tsx // 레이아웃 navbar 설정- navbar는 현재 같은 경로에 나타난다.app ㄴ 폴더명 ㄴ page.tsx // 페이지 명으로 폴더안에 page이름으로 만든다. ㄴ layout.tsx // 중첩 레이아웃 navbar 설정 ㄴ layout.tsx // 최상위 navbar- 중첩으로 나오게하려면 product/pageName 으로 진행되며, 중첩 폴더 페이지 안에 layout을 만들어줘야한다. function ProductsLayout({ children }: { children: React.ReactNode..

Next.js - 웹 어플리케이션을 만들기 위한 프레임워크 * 리액트는 자바스크립트를 이용하여 UI를 만드는 라이브러리 (Single Page Application, Cleant Side Rendering) - 리액트를 기반으로한 프레임워크 (리액트로 웹앱을 개발하는데 리액트로만으로는 힘든 다른 많은 것들을 가능하게 해 준다.) - by Vercel - Server-Side Rendering, Static Site Generation 그럼 라이브러리와 프레임워크는 무엇이 다를까? - 라이브러리 : 특정한 문제를 해결하기 위한 툴( 상태관리 툴, Routing, UI ) - 프레임워크 : 정해진 골격안에서 룰에 맞춰 코드를 작성해야 한다. 다양한 솔루션들이 정해져 있다. Next.js의 6가지 원칙 - 복..

리액트를 하면서 항상 고민하게되는 부분은 상태관리인거 같다. 이번 팀 프로젝트를 진행하면서 리덕스를 사용하지않고 ReactQuery와 Zustand를 통해 상태관리를 하기로 하였다. 두 상태관리 라이브러리의 차이와 목적에 대해서 정리해보려고 한다. 프론트엔드에서 상태관리에 있어서 가장 처음 만나게된건 리덕스였다. 리덕스를 하게되면서 전역관리를 알게되고 redux-toolkit, redux-saga, redux-thunk 등등 미들웨어도 사용했다. 리액트 상태관리는 리덕스? - 컴포넌트끼리 상태값을 직접 소통하게된다면 컴포넌트 재사용에 있어서도 좋지 않으며, 불필요한 리렌더링이 발생하거나 코드들도 복잡해지게된다. - 리덕스로 상태관리를 할때 장점도 있었지만 단점들이 있었다. 먼저 리덕스에 대해서 정리해보자..

쿠키 Cookie - 브라우저에 저장되는 작은 크기의 문자열 - 웹 서버가 웹 브라우저에게 보내져 저장 후 서버의 부가적인 요청이 있으면 다시 서버로 보내주는 문자열을 가진 정보 - 웹페이지 방문 시 방문기록 등의 정보들이 저장된 텍스트 파일 - 최대 4KB 저장 가능 - 쿠키는 서버를 대신해서 웹 브라우저에 저장하고 요청을 할 때 그 정보를 서버에 보내 사용자를 식별할 수 있다. - 서버에서 쿠키를 저장할 수 있기 때문에 서버에서 주로 사용된다. - 요청시 Headers에 전송된다. 쿠키 종류 - 기술적 쿠키 : 검색하는 주체가 사람 또는 App인지 이용자를 구분하는 기능 - 분석 쿠키 : 검색하는 종류, 검색량, 시간, 언어 대상의 정보를 수집 - 광고 쿠키 : 검색 내용, 국가, 언어에 따라 광고 ..

전체 디자인을 살펴본다. - 대량적인 큰 레이아웃을 구상 - 메인 컴포넌트를 분석 - 반복되는 컴포넌트를 구분 가변적인 요소가 들어가는 항목을 확인 - 이미지가 가변일 때, no image처리는 어떻게 되는가? - 이미지 비율이 다를때 어떤 기준으로 크롭하는가? - 텍스트가 가변일 때 몇 줄까지 노출하는가? / 번역 및 말줄임 - 값이 없을 때 0으로 노출하는지, 항목 자체가 사라지는지? 기획/디자인 측에서 요청한 인터랙션이 있는지? 마크업에는 정답이 없음. - 같은 화면이더라도 마크업 하는 방식은 개발자마다 모두 다름 - 모작을 하는 과정 혹은 다뤄보지 않은 레이아웃에 대한 고민이 있을 땐, 벤치마킹할 사이트의 코드를 훑어본다. - 주로 국내 서비스라면 네이버, 글로벌 서비스라면 구글이 좋은 예제