본문 바로가기

모카 스터디/React

한입 크기로 잘라 먹는 리액트 -일기장 프로젝트 one page-[인프런]

React에서 사용자 입력 처리하기

 

 

DiaryEditor 컴포 넌트 만들기

 

className과 컴포넌트 이름을 동일하게 해서 css스타일링할 떄 직관적으로 한다.

 

 

사용자의 입력을 처리하기 위해서는 state를 사용해야한다. ==> uesState를 사용한다.

 

onChange 사용

onClick 사용

스프레드 연산자 사용

공통된 State묶기

 

 

React에서 DOM 조작하기 - useRef

특정 길이 이상이 들어왔는지 확인

마우스 커서를 누르면 테두리가 진한 검정으로 바뀌나 커서가 깜박거린다.

UseRef 사용

 MutableRefObject는 hmtl 즉, DOM 요소를 접근 할 수 있게 한다.

레퍼런스객체(useRef)는 current 현재 가리키는 값을 가르켜 fouce 기능을 준다.

 

 

 

React에서 배열 사용하기 1 - 리스트 렌더링 (조회)

 

DiaryList, DiaryItem컴포넌트를 만들기

 

 

 

 

React에서 배열 사용하기 2 - 데이터 추가하기

같은 레벨로 한번에 자식을 추가 할 수 없다.

DaryEdiotr에서 추가한 값을 DiaryList에 추가를 해야하는데 방법이 없을까 ?

state를 공통 부모로 올려서 해결 !

 

 

data는 배열이고 하나의 일기 데이터(item1)라 가정. 즉, 하나의 데이터만 렌더링하고 있다고 가정.

새로운 일기가 작성이 되면 app컴포넌트가 Editor 컴포넌트 prps으로 전달한 setData를 전달하게 된다.

즉 데이터 가 추가되고 그 추가된 데이터가 props으로 List 컴포넌트로 내려간다. ==> 리랜더링

즉 위와 같은 과정으로 리액트의 단반향 데이터 방식을 극복할 수 있다.

즉, 리액트로 만든 컴포넌트들은 트리 형태를 띄며 이벤트들은  아래서 위로 데이터들은 위에서 아래로 이동한다. ==> state끌어 올리기

 

 

 

 

 

 

 

 

React에서 배열 사용하기 3 - 데이터 삭제하기

 
 
 
 
 
 

 

React에서 배열 사용하기 4 - 데이터 수정하기

 
 
수정하기 버튼을 누르면 새로운 입력 폼이 떠야해서 state를 새로운걸 생성
 
 
 

 

 
 
 
데이터는 위에서 아래로 ! 이벤트는 아래에서 위로 !
 
 
수정완료 이벤트를 app컴포넌트에 전달 하기 위해서는 데이터를 가지고 있는 app컴포넌트에 수정하는 기능을 가진 함수를 하나 만들어서
itme 컴포넌트까지 넘겨줘야한다.
그래서 item의 폼을 수정하는 것이니까 item의 부모인 list 컴포넌트의 Props으로  onEdit를 준다.
그리고 다시 item의 onEdit를 props으로 넘겨준다.
 
==> 결론 : 수정 완료 버튼이 눌러지면 onedit함수가 실행되고 list컴포넌트를 타고 올라가 app컴포넌트까지 올라간뒤
app의 onedit이 실행되고  그 콜백함수인 setData 메소드가 실행되어 data를 바꿔서 스테이트를 바꾼다 ! 후!
 
 
 
 
 
 
 
 

React Lifecycle 제어하기 - useEffect

 
 
 
해당 생명주기(lifeCycle)에서 다른 일들을 진행 할수 있는걸 생명주기를 컨트롤한다고 말한다. 
 
 
 
이런 메소드들은 클래스형 컴포넌트에서만 사용할 수 있다.
하지만 지금까지 우리는 화살표 함수를 사용해서 컴포넌트를 만들어왔다.
원래 state도 클래스형 컴포넌트에서만 사용이 가능하다. 하지만 useState를 사용해서 지금까지 state를 관리 했었다.
 
클래스형 컴포넌트들이 가지고 있는 것들을 함수형 컴포넌트에서도 사용할 수있게 가져오는걸 Hook이라고한다.   [use]
 
 
useEffect는 리액트의 라이프사이클을 컨트롤할수 있게 하는 훅이다.
 
 
클래스형 컴포넌트의 길어지는 코드 길이 문제(중복코드, 가독성문제) 를 해결하기 위해 훅이 등장했다.
 
 
의존성 배열 중 하나라도 변하면 콜백함수가 다시 수행된다.
 
 
 
 
마운트 시점에 무언갈 하고 싶다?
 
 
의존성 배열에 빈배열을 넣고 할 일을 콜백함수로 작성
 
 
 
 
 
 
업데이트(리렌더링)가 될떄 무언갈 하고 싶다?
업데이트는 state가 변경되거나 부모에게 받는 props가 바뀌거나 부모 컴포넌트가 리렌더링 될떄 발생
 
 
의존성 배열을 아무것도 주지 않으면된다.
 
 
 
 
 
의존성 배열이 바뀌면 콜백이 실행 되므로 왼쪽(카운터 컴포넌트), 오른쪽(텍스트 컴포넌트)가 변경 될때 콜백이 실행되는걸 활용
==> 의존성 배열을 잘 활용하면 감지하고 싶은거만 감지해서 작업을 할 수 있다.
 
 
언마운트 시점에 무언갈 하고 싶다?
 
마운트를 제어하는 useeffect의 콜백 함수가 함수를 리턴하게 !
 
 
 
 
 
 
 
 
 
 
 
 

React에서 API 호출하기

컴포넌트가 등장하는(마운트) 시점에 api를 호출하고 api의 결과값을 일기 데이터의 초기값으로 이용ㅎ !

api의 응답 데이터를 app컴포넌트가 가지고 있는 일기 데이터에인 데이터state에 저장하는 실습

 

 

바디는 본문으로
이메일은 작성자로 일기 데이터의 기초값을 설정해 보자 !
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

React developer tools

크롬 확장프로그램을 설치하여 

이렇게 우리가 만든 컴포넌트의 계층구조를 보여준다.

 

어떤  state,ref,effect,propsㄹ를 받았는지를 알수 있따.

어떤 컴포넌트가 리렌더링 되고 있는지 하이라이트로 알려준다.

 

최적화 1 - useMemo

 
 

 

일기 내용을 수정할때는 일기의 갯수들은 변하지 않지만 수정완료를 하면 모든 컴포넌트가 리렌더링된다.

불필요한 컴포넌트 리렌더링을 줄여보자 ==> memoization      useMemo

의존성배열이 수정 될때만 콜백 함수가 다시 수행 되게 된다.

또한 usememo의 반환값은 함수가 아니라 값!이다  !

 

 

 

 
 
 

최적화 2 - React.memo

 
처음 setcount가 실행되면서  app 컴포넌드의 값을 변화 시키려 한다.
스테이트가 변경되었기 때문에 스테이트를 가진 app컴포넌트는 리렌더링 된다.
부모컴포넌트가 리렌더링되면 자식컴포넌트도 리렌더링 되기 때문에 불필요한 text 컴포넌트도 리렌더링 되게 된다.
==> 연산의 낭비가 일어난다.
 
 
 

리액트 공식 문서를 참조 해서 공부해 보자 !

https://ko.legacy.reactjs.org/docs/getting-started.html

즉, props가 변하지 않으면 바뀌지 않는 컴포넌트를 주면 그 컴포넌트의 props가 변하지 않으면 리렌더링 안시키는 
강화된 컴포넌트로 돌려주겠다 !
 
 
props인 test가 바뀌지 않으면
렌더링이 일어나지 않는다.
 
 
 
 

props가 객체이면 얕은 비교를 한다.

 

 

 
앝은 비교 ==> 같은 주소에 있냐를 비교

 

카운터 A에 대해서는 같은 변수로 되는것이어서 리렌더링이 일어나지 않지만

카운터 B의 경우에는 얕은 비교로 인해 객체가 다른걸로 인식하여 리렌더링이 된다 !

 

 
 
 

최적화 3 - useCallback

 

의존성 배열이 바뀌지 않으면 첫번째 인자로 전달한 콜백함수를 재사용할 수 있도록 한다.
즉, 불필요한 함수의 행성과 참조를 방지할 수 있다.
 
 
 
업데이트형 함수를 setData에의 인자로 넘겨준다.
 
 
 

 

 

 

복잡한 상태 관리 로직 분리하기 - useReducer

app컴포넌트에는 많은 상태변화 함수가 있다.  ==> 컴포넌트의 코드가 길어진다.

==> 상태변화 로직들을 컴포넌트에서 분리 시킬 수 있다.

 

useRducer는 useState의 훌륭한 대체제이다.

즉 이제 setData가 할 일을 dispatch가 하게 된다.

dispatch는 호출을 하면 현재 state를 reuder함수가 참조한다.

 

 

컴포넌트 트리에 데이터 공급하기 - Context

Provider컴포넌트는 자신의 자손에 해당하는 모든 컴포넌트 들에게 직통으로 데이터를 전달 해 줄 수 있따.

 

 

 

Provider가 데이터 공급 할시 위와같이 공급한다 

 

Provider에게 공급을 받을 시에는 위와 같이 받는다.

 

 

 

데이터를 공급하는 Provider와 함수를 보내주는 Provider를 따로 생성한다.