# useContext
React - Data Caching
Data Caching? Data Caching이란 반복적으로 엑세스되는 데이터를 빠르게 사용할 수 있도록 메모리에 일시적으로 저장하는 프로세스를 의미한다. 데이터 캐싱으로 얻을 수 있는 이점이 많기에 성능 향상과 효율적인 리소스 사용을 위해 필수적으로 사용되고 있다. 데이터 캐싱의 이점 속도 향상 : 캐시 메모리는 RAM과 같은 저장소에 위치하므로 외부 서버에 접근하는 것보다 빠르게 엑세스할 수 있다. 부하 감소 : 반복적으로 요청되는 데이터를 캐시에 저장함으로써 서버로의 데이터 요청 수를 줄일 수 있다. 사용자 접근성 향상 : 캐시된 데이터로 빠르게 화면에 사용자가 원하는 데이터를 보여줄 수 있다. 데이터 캐싱이 없다면 아래 화면처럼 페이지가 렌더링 될 때마다 데이터를 서버로 부터 가져 오기에 loading 메시지가 반복된다. 
Context, Provider, useContext, useReducer
1. Context 객체의 형태로 전역 데이터를 담는 그릇 2. Prodiver 컴포넌트를 Provider로 감싸주면, 그 하위 모든 컴포넌트들이 Context에 있는 전역 데이터에 접근할 수 있음. value 속성을 지정해주어야 함. value 값이 바뀌면, Provider에 속해 있는 컴포넌트들이 모두 렌더링됨. 3. useContext Context의 데이터를 가져올 수 있음 자식 컴포넌트에서 데이터를 받아올 수 있음 이런 식으로 전역 변수를 불러올 수도, state를 불러올 수도, dispatch를 불러올 수도 있음 4. useReducer 선언하면, state와 dispatch가 만들어짐. state는 useState에서 사용하던 그 상태임 dispatch는 reducer라는 로직을 지니고 있는 액션 실행 로직 함수임 dispatch를 전역에서 사용할 수 있게 하려면(stat
[React] useContext (Context API)
useContext 란? 리액트로 만든 앱은 여러 개의 컴포넌트로 이루어져 있다. 이 컴포넌트는 최상위 App 컴포넌트로 시작해서 트리 형태로 뻗어나간다. props를 전달할 때는 부모 컴포넌트에서 자식 컴포넌트로 단계별로 전달하게 되는데, 이 때 React Context를 활용하면 리액트 앱에서 전역 데이터를 쉽게 공유 및 관리할 수 있다. 즉, props로 data를 일일이 내려보내주지 않아도, 하위 컴포넌트에서 필요하다면 해당 데이터 값에 접근할 수 있다. Context를 사용하면 여러 컴포넌트가 사용해야 하는 전역적인 데이터를 사용할 때 편리하다. useContext 사용법 > Context 생성 해당 Context 내보내기 (export) App.js에서 해당 Context 가져오기 (import) Context 태그(.Provider)로 컴포넌트를 감싸고, value에 공유할 데이터 값을 적어준다. (value=
내가 Context API 대신 Zustand 라이브러리를 사용한 이유
Context API와 Zustand 예시 코드를 보기만 해도 Zustand를 사용하는 이유를 알 수 있다. 사용이 간편하고 초기 세팅(보일러플레이트) 코드가 비교적 적다. 위 예시 코드를 보면 확실히 Zustand의 코드가 적고 손쉽게 작성할 수 있다. Context API와 달리 Provider를 사용하지 않아 Provider hell 문제를 해결할 수 있다. Context API를 사용하다보면 Provider를 감싸야 하는데 Zustand는 Provider 없이 커스텀 훅처럼 사용할 수 있다. Context API는 Provider에 의존하는 모든 컴포넌트를 재렌더링하지만, Zustand의 셀렉터 함수를 활용하면 재렌더링을 쉽게 방지하여 관련된 컴포넌트만 재렌더링을 시킬 수 있다. store 안에 필요한 상태만 선택하여 불필요한 재렌더링을 손쉽게 피할 수 있다. 간단하게 persist 미들웨어를 활용하여 로컬스토리지와 손쉽게 동기화하여
React 스터디 4주차 global state - useContext
글로벌 state 관리는 왜 필요할까? 리액트에서의 context 가 무엇인지 아는가? 일반적으로 리액트에서 부모 컴포넌트에서 자식 컴포넌트로 정보를 전달할 때 props 를 통해 정보를 전달한다. 그런데 만약 중간에 많은 컴포넌트가 있거나 같은 정보를 필요로 하는 컴포넌트가 많을 때 props 를 전달하는 것은 복잡해질 수 있다. 가장 가까운 공통 조상은 해당 데이터를 필요로 하는 컴포넌트들로부터 멀리 떨어질 수 있고 lifting state up 은 해당 데이터를 얻기 위해 컴포넌트가 계층 구조를 거치며 prop drilling 이라고 불리는 번거로운 상황을 초래할 수 있다. | props 를 순서대로 전달할때 | 글로벌 state 를 사용할 때 | | --- | --- | | |
컴포넌트 트리에 데이터 공급 (Context)
모든 데이터를 가지고 있는 컴포넌트가 Provider라는 공급자 역할을 하는 컴포넌트에게 자신이 갖고 있는 모든 데이터를 전달한다. 이 Provider라는 컴포넌트는 자신의 자손에 해당하는 모든 컴포넌트에게 직통으로 데이터를 전달할 수 있다. Provider 컴포넌트의 자식 컴포넌트들로 배치되어 해당 Provider 컴포넌트가 공급하는 모든 데이터에 접근할 수 있는 컴포넌트들의 영역을 context(문맥)이라고 한다. 기본공식 : 1. Context 생성 React.createContext를 사용하여 Context를 생성한다. 컴포넌트 파일에는 export default App; 과 같이 컴포넌트를 내보내는 export default가 포함되어 있다. 이와 마찬가지로 Context 역시 export를 통해 내보내줘야 하는데, 다른 컴포넌트들이 Context에 접근하여 공급자가 공급하는 데이터를 받아올 수 있어야 하기 때문이다. **한 파일
[React] 다크 모드 구현하기(feat. useContext)
저번에는 https://velog.io/@kiminn/React-useContext란 를 통해서 useContext에 대해서 알아봤습니다 이제 useContext를 사용하여 사용자 입장에서 너무나도 당연해져버린 웹 페이지의 다크 모드 테마를 구현해보겠습니다 App.js(상태) > Page.jsx(X) > Header & Content & Footer(상태) 
[React] useContext란?
사진 출처: https://www.youtube.com/watch?v=LwvXVEHS638 > ### 🍀 useContext 부모가 자식 컴포넌트에게 데이터를 전달하는 과정에서 필요한 컴포넌트에만 전역적인 상태의 값을 전달할 수 있음 (* Props Drilling 해소) => 글로벌 데이터(Theme, Language, User)와 같은 전역적인 데이터 관리에 유용 * Props Drilling: 부모 컴포넌트가 자식 컴포넌트로 props를 전달할 때 발생하는 구조적 문제 (필요로 하지않는 중간 컴포넌트까지 props를 전달할경우 디버깅이 복잡해짐) 일반적으로 리액트에서는 Props(자식선택자)를 이용하여 각 컴포넌트에 데이터를 전달합니다 하지만 아래 그림에서 보면, 맨 아래의 C와 E만 APP의 데이터를 필요로 하는데도
[23.08.09] 리액트 훅 - useContext
useContext : [공식문서 ] ' context를 이용하면 단계마다 일일이 props를 넘겨주지 않고도 컴포넌트 트리 전체에 데이터를 제공할 수 있습니다. ' 기존 props 를 통한 데이터 전달방식은 부모에서 자식으로 또 그 자식으로 그 자식의 자식으로.. 중간 컴포넌트를 꼭 거쳐야하는 prop drilling 현상이 일어나게 된다. 이럴 때 React에서 제공하는 Context와 Context를 쉽고 간단한게 사용할 수 있는 useContext를 사용 할 수 있다. context API 필수 개념 createContext : context 생성 Provider : context 전달(to 하위 컴포넌트) Consumer : context 변화 감지 예시코드 (Context) context폴더 > FamilyContext.js
Section 6. useEffect, useReducer, Context API 사용하기
📍 Effect >UI와 직접적인 관련이 없는 것은 side effect라고 부른다. side effect들은 http request 보내기, 브라우저에 데이터 저장하기 등 화면에 UI를 rendering하는 기능 외의 것들을 담당한다. 즉 백엔드와의 통신에서 중요하게 사용되는 기능이다. 이러한 effect는 component 함수 내부에서 동작하면 안된다. component함수는 리액트에 의해 자동으로 실행되므로, 내부에 effect를 둘 경우 계속해서 re-rendering되거나, state가 변할 때 마다 http request를 보내는 등의 문제가 발생한다. 실제 웹에서 로그인을 하면 백엔드에 request 보내서 로그인 데이터를 가지고온다. 예를 들면 이 유저가 인증되었다는 토큰과 같은 정보를 가지고온다. 하지만 인증부분은 나중 section에서 다룰 것이기 때문에 여기서 useEffect()를 정리할 때는 백엔드 서버를
React Native useContext 값 전달 안됨
에러 났던 코드.. user를 가져오는 부분이 userprovider 안에 있어야 한다고 한다. 코드를 나누니 제대로 된다.
localStorage, debounce, useReducer, useContext , forwardRef, useImperativeHandle
키워드 값이 바뀔 때 서버에서 키워드로 자동완성 된 데이터를 받아왔을 때 useEffect Synchronizing with Effects 로컬스토리지 localStorage.setItem(“isLoggedIn”,”1”) localStorage.removeItem(“isLoggedIn”) 유효성 검사 debounce : 일정 시간 안에 동일 이벤트가 다시 발생하면 마지막 발생 시점부터 일정 시간을 지연한다. useReducer 복잡한 상태 다룰 때 useState로 하게 되면 side effect 발생 useReducer 하나의 복잡한 상태를 여러 타입으로 dispatch 하기에 적합 useContext state,props의 한계 전역상태관리 Context 한계 잦은 변화가 일어나는 상태를 다루기에 적합하지 않음=>성능 떨어짐 모든 컴포넌트 간 통신을 다 co
[React] Hooks이란? Hooks 종류
Hooks란? > React 에서 기존에 사용하던 Class를 이용한 코드를 작성할 필요 없이, state와, 여러 React 기능을 사용할 수 있도록 만든 라이브러리 hook은 class 안에서는 동작하지 않고, class 없이 react 사용이 가능하게 해준다. Hooks의 종류? 1) useState 현재 state 값을 업데이트하는 함수를 반환 원형 2) useEffect 리액트 컴포넌트가 렌더링 될 때마다, 즉 DOM이 렌더링 된 이후에 작업을 실행할 수 있도록 명시함 -> 컴포넌트 렌더링 - 화면 업데이트 - useEffect 실행 => 생명주기의 메소드 기능을 수행 첫 번째 인자: 콜백함수 -> 컴포넌트가 마운트되거나 업데이트 될 때마다 실행되는 함수, 콜백 함수 내부에서 원하는 작업 수행 가능 두 번째 인자: 의존성 배열 -> 배열에 포함된 값은 콜백 함수가 실행되는 조건을 지정, 즉 배열에 포함된 값들 중 하나라도 변경
[React] useContext, Provider
구현 기능 입력 값에 따른 새로고침 없이 바로 메뉴 검색 입력 값에 따라 더미데이터에 있는 메뉴 자동완성 자동 완성 클릭 시 해당 메뉴 렌더링 변경 및 추가된 컴포넌트 css는 생략합니다. MenuProvider.js Meals.js AvailableMeals.js MenuSearch.js 구현 목표 useContext, context, Provider에 대한 이해 이를 사용할 때 컴포넌트 간 로직 흐름의 이해 전역 관리의 필요성 이해 MenuProvider 컴포넌트 음식 관련 상태와 함수를 관리하기 위한 컨텍스트(provider) 역할 createContext()를 사용해서 MenuContext 생성 → 이 Context는 MenuProvider에서 생성된 state와 state 함수를 자식들과 공유하기 위해 사용 현재 사용자가 검색하기 위해 입력하
[Next.js] useContext
Next.js로 토이프로젝트를 만들면서 전역상태관리가 필요해서 useContext를 사용해봤다. 평소에 Redux-toolkit만 사용했는데 이번엔 관리할 데이터가 적어서 굳이 redux를 사용하는것보단 react에서 제공되는 useContext를 사용하는게 간편하기도하고 코드도 간단해 보여서 사용하게 됐다. 내가 관리할 데이터는 [[1,2,3,4], [5,6,7,8]]과 같은 number 배열로 이루어진 배열이었다. createContext를 import해서 context를 만들어준다. 초기값을 지정해주고 context에 전달한다. _app.tsx에서 useState를 이용해 상태값과 필요한 업데이트 함수를 작성해주고 ResultContext.Provider의 value에 전달해주면 된다. context provider를 통해 value를 전달해주게되면 해당 컴포넌트의 하위컴포넌트에서 전역상태값에 접근할 수 있다. _ap
React hook의 모든 것(6) (Context와 useContext)
1. Props drilling과 전역상태관리 1) Props drilling이란? 전역상태관리를 사용하지 않는 경우, 특정 컴포넌트에서의 state 변화를 다른 컴포넌트에게 전달하기 위해 여러차례 props를 전달해야한다.(이를 props drilling 이라고 부름) 예를 들어, 어떤 페이지를 만드는데 Header안에 다크모드 버튼이 있다고 해보자. Header안의 다크모드 버튼을 누르면 Header, Content, Footer의 색이 다크모드로 전환이 되어야 한다. React는 단방향으로만 데이터가 흐른다. (= 부모 컴포넌트에서 데이터를 props로 자식들에게 전달은 가능하나, 자식들간에 props교환은 안된다.) -> 만약에 전역상태관리를 사용하지 않으면, App.js에서 다크모드 상태를 선언하고 자식 컴포넌트로 여러 차례 전달해줘야한다(props drilling) App.js에서 Page1으로, Page1에서 Page1의 자식 컴포넌
[React Docs] useContext
useContext란 > 컴포넌트에서 context를 읽고 구독할 수 있게 해주는 리액트 훅이다. > useContext(SomeContext) 컴포넌트의 useContext() 호출은 동일한 컴포넌트에서 반환된 해당 `는 반드시 useContext()` 호출을 수행하는 컴포넌트의 위에 있어야 합니다. 변경된 value를 받는 provider부터 시작해서 해당 context를 사용하는 자식들에 대해서까지 전부 자동으로 리렌더링 memo로 리렌더링을 건너뛰어도 새로운 context 값을 받는 자식들을 막지는 못한다. 사용방법 컴포넌트 최상위 레벨에서 호출한다. useContext는 전달한 context에 대한 context값을 반환하고 위에서 가장 가까운 context Provider를 찾는다
훅(hook)
Hook은 React 버전 16.8부터 React요소로 새로 추가되었습니다. Hook을 이용하여 기존 Class 바탕의 코드를 작성할 필요 없이 상태 값과 여러 React의 가능을 사용할 수 있습니다. React 훅(hook) 규칙 최상위 레벨(at the top level)에서만 hook을 호출하는 것을 권장한다. 반복문, 조건문, 중첩 함수(nested function) 내에선 hook을 호출하지 않는 것이 좋다. 유지보수성 높은 React 프로젝트 설계를 위해선, React 함수의 최상위(at the top level)에서 hook을 호출하는 것을 권장한다. 이 규칙을 따르지 않으면 컴포넌트가 렌더링 될 때 마다 항상 동일한 순서로 hook이 호
[React] useContext hook
함수형 프로젝트를 진행하는데, 전역으로 관리할 state가 많지 않아서 useContext를 사용한다. ( 현재까지는 user 정보만 가지고 다니면 됨 ) 폴더구조 src/hooks/TestContext.js useContext hook을 사용하여 컴포넌트 생성 src/App.js App 단에 전역으로 전달 src/views/Dashboard.js 실제 전역으로 관리되는 state 값 사용하는 컴포넌트 Dashboard 화면
[주문앱 8탄] context API로 리팩토링하기
🧹 개요 오늘은 저번 포스팅에 이어 Context API를 사용하여 상태를 관리할 수 있도록 리팩토링한 과정을 다뤄보려고 한다. 아래는 기존의 방식으로 상위 컴포넌트에 있는 prop을 하위 컴포넌트로 전달하는 과정이다. prop을 주고 받는 컴포넌트의 사이가 멀수록 prop을 전달하는 코드로 인해 코드가 장황해진다. 이를 prop drilling이라고 한다