프론트엔드의 데이터에 대해서 글을 써보려고 합니다.
하드코딩
데이터를 직접 변수나 json으로 데이터를 저장해서 사용합니다. 이런 방법을 쓴다고...? 라는 생각이 들 수 있는데요. 실재로 사용합니다...!!
왜 이런 방법을 사용할까요 ?
이게 이상적인 구조에 대해서는 잘모르겠습니다. 하지만 현업에서는 시간과 비용이라는 제약이 있고 그 제약속에서 빠르게 개발을 해야하는 순간이 많습니다. 예를 들어서 특정 페이지에서 별도의 상품들을 불러와야하는데 이것을 서버에서 받으려면
- 어드민 프론트 작업
- 어드민 백엔드 작업
- 서비스 프론트 작업
- 서비스 백엔드 작업
이렇게 4번의 공수가 발생하는데요
프론트에서 하드코딩을하면 위의 4번의 공수가 1번으로 줄어듭니다.
물론 데이터가 바뀌어야할때마다 프론트를 새로 배포해야함과 데이터 관련된 값이 소스코드에 노출된다는 단점도 있다고 생각합니다.
내부 상태
React에는 상태(state)라는 개념이 있습니다.
useState, context api, useReducer로 내부의 상태를 관리합니다.
React의 컴포넌트의 데이터를 화면에 그릴때주로 사용합니다.
상태값이 바뀌면 화면을 다시 그리는 특징이 있습니다.
리액트에서는 이런 상태값을 단방향 바인딩으로 관리합니다.
단방향 바인딩 ? 양방향 바인딩 ?
리액트는 단방향 바인딩을 사용하고 (양방향 사용할 수도 있긴함, ref 사용), Vue는 양방향 바인딩을 사용합니다.
대단한 개발자, 유튜버 단테님의 블로그 글을 보고 배운 내용입니다.
단방향 바인딩
단방향 바인딩은 유저 이벤트 => 상태 변경 => ui변경 이러한 방향으로 이동합니다.
양방향 바인딩
유저의 이벤트로 발생한 입력과 변수를 핸들러 없이 연결 해줍니다.
자세한 내용은 단테님 블로그 참고하시면 될거 같습니다.
외부 상태
위에 내부 상태에 있는 useState는 다른 컴포넌트에게 전달하려면 props로 내려줘야 합니다.
jotai, zustand, recoil 등등 라이브러리를 사용해서 외부 상태를 관리합니다.
또한 React의 useSyncExternalStore라는 훅을 사용하여 외부 저장소와 연동을 시킬 수도 있습니다.
useSyncExternalStore
이 훅은 react 18에서 concurrent mode가 나오면서 나온 훅으로 외부의 저장소를 연동시켜주는 훅이다.
useContext를 사용할수도 있지 않나요 ?
그렇긴한데 최적화를 직접 개발자가 해야하고 다양한 유틸 기능을 제공하지 않아서 직접 구현해야합니다.
외부 상태 라이브러리들
위에도 언급했든 redux, redux toolkit, recoil, zustand, jotai등의 라이브러리를 많이 사용합니다.
npm trend를 보면 redux가 엄청 많긴 하지만 사용해본 결과 너무 코드가 많고 더러운 느낌이 있어서 상대적으로 코드량이 적고 번들사이즈가 작은 jotai를 좋아합니다.
회사에 다른 프론트분이 zustand엄청 좋다고 말씀하시는데 안써봐서 잘모르겠습니다. 다음에 기회가 되면 한번 써봐야겠네요.
서버 상태
서버에서 받아온 데이터를 프론트에서 사용하는 방법입니다.
- react query (tanstack query)
- swr
- redux saga
등의 라이브러리를 사용해서 관리합니다.
react query (tanstack query)
저는 서버 상태 라이브러리에서 react query(tanstack query)를 가장 선호하는데요.
- 기본적인 데이터 fetching에 필요한 기능들을 다 제공 (loading, error처리 등등)
- suspense 기능 제공 (선언형으로 코드를 사용할 수 있게 제공해줍니다.)
- 쉬운 캐싱 관리 query key를 사용해서 손쉬운 관리가 가능합니다. (props로 계속 안내려줘서 너무 편합니다.)
- prefetch
브라우저의 저장소
프론트엔드 개발자라면 브라우저의 저장소도 많이 사용합니다.
쿠키
next js로 서버까지 다루는 프론트엔드 세상이 온 뒤로 SSR을 사용하려면 데이터 fetching에 데이터를 cookie나 query string에 저장해야합니다.
쿠키는 여러가지 특징이 있습니다.
- 서버에서 request에 담아서 보낼 수 있습니다. (SSR할때 유용합니다.)
- 유효 일자나 만료 기간을 지정할 수 있다. (지정 안하면 브라우저 닫으면 없어집니다.)
- httpOnly 옵션으로 브라우저에서 접근을 막을 수 있다.
- name=value는 4KB를 넘을 수 없다.
- 도메인 하나당 저장할 수 있는 쿠키의 개수는 정해져있다.
스토리지
로컬 스토리지, 세션 스토리지 두가지의 저장소가 있습니다.
로컬 스토리지
직접 지우지 않는 이상 영구적으로 저장됩니다.
세션 스토리지
브라우저를 닫으면 사라지는 저장소입니다.
indexed DB
한번도 사용해보지 않은 저장소입니다.
DB하니... 뭔가 데이터 베이스?가 먼저 떠오르는 이름이네요. (진짜였음)
이러한 특징들이 있는거 같습니다.
- 브라우저에 영구적인 데이터 저장이 가능하다.
- 오프라인상태에서도 사용 가능하다.
아직 사용해보지 않은 저장소라서 아는게 적은데 나중에 사용해보면서 차근차근 학습해볼 예정입니다.
query string
얼마전에 유튜브 코딩애플님의 영상을 봤는데요. url에 다양한 데이터를 넣어서 관리하는 방법이 나와서 신기하게 봤습니다.
url에 데이터를 넣어서 관리하면
- 새로고침해도 데이터 유지
- url그대로 공유하면 똑같은 데이터를 공유
이러한 장점들이 있습니다.
저장할 수 있는 양은 브라우저별로 다른데 몇만자까지 저장할 수 있는것으로 보여집니다.
