리액트의 라이프사이클과 함수형 컴포넌트의 Hook
Mount Update UnMount 라는 세가지 주기를
클래스형 컴포넌트 시절에 어떤 것들을 가지고 어떻게 관리했었는지 학습했었다.
그리고 함수형 컴포넌트에서는 클래스형 컴포넌트의 생명주기 함수들을 어떻게 관리하고
어떻게 관리할 수 있게 되었는지도 학습했다.
React Hooks
클래스형에서는 React.Component 라는 클래스를 상속받아 그것들이 가진 생명주기 메소드나
생성자를 재정의하여 사용하는 형태였다.
필수 또는 부가적인 인터페이스들이 제공되고 이를 구현해야만 컴포넌트로써 상태와 생명주기를 관리할 수 있었다.
함수형 컴포넌트는 말 그대로 컴포넌트가 jsx를 리턴하는 함수 그 자체 뿐이다.
간단한 UI적인 컴포넌트라 상태와 생명주기 관리가 필요없다면 정말 없어도 된다.
리액트 16.8버전에 추가된 Hook을 통해 상태관리와 라이프사이클 관리를 컴포넌트 자체에 종속시킬 필요가 없고
많은 것들을 생각할 필요 없이 단순히 선언하여 사용할 수 있게 추상화되었다.
말 그대로 컴포넌트에 hook을 걸어 끼우기만 하면된다.
언어스터디 시간에 클래스형과 함수형 컴포넌트의 생명주기와 상태 관리 차이를 알아보고자
코드샌드박스로 구성해보고 설명했었다.
Closure
결국 함수형 컴포넌트가 클래스형 컴포넌트를 대체할 수 있게 된 이유이다.
속성과 동작의 틀을 가지고 인스턴스화 해서 독립적으로 생명주기를 가지고 다른 객체와 상호작용하게끔 설계된 클래스라는 것을 사용하지 않아도 된다.
클로저는 클래스처럼 속성을 은닉화 해주고 속성을 제어하는 함수들을 제공해줘
다른 스코프에서 사용할 수 있게 해준다.
클래스가 인스턴스가 되듯 어딘가에 할당되어 독립적인 생명주기를 가진다.
클로저 함수 그 자체는 할당되어 생명이 끝난 것으로 보이지만 내부적으로 정의되었던 속성은
클로저 함수의 리턴으로 넘긴 컨트롤 콜백함수들로 계속해서 제어 가능하다.
export function useState<S>(
initialState: (() => S) | S,
): [S, Dispatch<BasicStateAction<S>>] {
const dispatcher = resolveDispatcher();
return dispatcher.useState(initialState);
}
export function useReducer<S, I, A>(
reducer: (S, A) => S,
initialArg: I,
init?: I => S,
): [S, Dispatch<A>] {
const dispatcher = resolveDispatcher();
return dispatcher.useReducer(reducer, initialArg, init);
}
export function useRef<T>(initialValue: T): {current: T} {
const dispatcher = resolveDispatcher();
return dispatcher.useRef(initialValue);
}깃허브의 리액트 프로젝트를 까서 React-Hook 파일 내부를 확인해보았다.
결국 하나의 컴포넌트 또는 훅에 훅을 선언하여 사용하는 것 자체도
뭐하는 애인지 정확히는 모르겠지만 resolveDispatcher라는 클로저 함수를 이용하는 것으로 보였다.
예를 들어 useState라는 애를 컴포넌트에서 사용한다면 새로운 resolveDispatcher()를 호출해 해당되는 hook 함수를 결과로 전달해주는 것이다.
그래서 하나의 컴포넌트에 존재하는 모든 hook들이 독립적으로 주기를 가지고 동작할 수 있었던 것이지 않나 생각했다.
hook의 내부 동작 그 자체도 클로저일 것이라고 생각한다.
16.8버전 릴리즈의 풀리퀘스트에서 찾을 수 있을까 싶어 뒤져보았지만
아쉽게도 실제 내부 구현부를 찾지는 못했다.
최소한으로만 useState를 생각해보면 state라는 내부 속성이 있고
setState라는 변경 함수와 getter를 제공해주는 형태일 것이다.
아무래도 함수형 컴포넌트만 접했었고
자바를 공부하다 와서 클래스를 활용한 프로그램의 사이클이
어떻게 함수로 대체가 될 수 있었는지 처음에 굉장히 의문이었는데
클로저를 공부하게 되면서 어느정도 이해가 된 것 같았다.
클래스형 컴포넌트의 동작원리를 아예 버리고 새로운 방식이 생긴 것이 아닌
동작원리를 단순하고 쉽게 추상화 해준 것이라고 이해했다.
Redux
전역상태관리 라이브러리인 redux를 리액트에서 먼저 사용해보고
redux-toolkit으로 패턴을 한 번더 추상화한 형태로 만들었고
thunk로 비동기 api 상태관리를 처리해보았다.
사실 기본 리덕스로 덕스패턴 형태를 구현해보기 전에 deprecated 줄을 보고 눈이돌아가
공식문서를 보며 toolkit으로만 적용해보았었다.
그래서 toolkit으로 slice를 사용하는 것이 어떻게 패턴을 그대로 따른 것인지에 대해
공부하고 매니저님에게 설명해보는 시간을 가졌었던 것 같다.
ducks pattern
액션 타입(Actions),
액션 생성 함수(Action Creators),
리듀서(Reducer)가
모두 들어있어 하나의 파일에 작성하는 것
toolkit slice의 구조
name : string,
reducer : ReducerFunction,
actions : Record<string, ActionCreator>,
caseReducers: Record<string, CaseReducer>.
getInitialState: () => State슬라이스는 액션 생성자와 리듀서를 정의하고 내보내기 위한 "Redux Ducks" 패턴과 개념상 매우 유사합니다.
개념적으로 "Redux duck" 코드 구조와 유사합니다. 사용하는 실제 코드 구조는 사용자에게 달려 있습니다.
기존에는 액션생성함수와 액션 타입을 선언해 사용했다면
createSlice 는 액션을 선언하고 해당 액션이 dispatch 되면 바로 state을 가지고 해당 액션을 처리하게끔 된 것이다.
기존 덕스패턴을 보일러 플레이트를 줄여 추상화 한 것이라고 이해했다.
thunk
redux thunk의 경우 코드나 문법은 좀 생소해 팀원의 코드를 보고 복붙해 바꿔서 활용하는 식으로 사용했다.
근데 사용해보니 어딘가에서 비슷한 걸 본 적이 있었다. react-query라고
stale cache 나 pre-patching 같은 부분 말고 단순하게 사용되는 부분에서는 그렇게 느껴졌었던 것 같다.
react-query같은 경우는 비동기 데이터 상태 관리 전용이었고
isLoading, error 등의 다양한 상태와 비동기 api 호출 상태를
자체적으로 제공해주어 되게 편했었다.
팀과제
우리팀은 익명게시판을 구현하기로 했다.
wireframe, 요구사항
와이어프레임을 만들고 api 요구사항을 만든 뒤
개발 요구사항 체크리스트를 만들어보았던 것 같다.
어떤식으로 개발을 해나가야할지 너무 고민이 되서 작성해보았던 것 같다.
한가지 느꼈던 것은 프로젝트를 진행하기 위해 필요한 공통적인 정의나 동작들은
미리 설정할 수 있다면 하는게 좋을 것 같다는 것이다.
아니면 적어도 껍데기라도 구성해두는 것이다.
특정 동작을 위한 공통 함수가 모여있을 곳에 대한 파일을 미리 만들어둔다던가?
디렉터리 구조나 네이밍 컨벤션들도 정할수 있다면 최대한 정해놓고 시작하는게 좋을 것 같다.
jsonserver
json-server를 이용해 api를 mocking한 채로 구현하고 있다.
따로 api관련 요청응답 설정을 안했는데도 crud가 되서 엄청 신기했다.
그런데 해피한 상황, 즉 어차피 200응답을 얻어내서 사용하는 곳에는 정말 편해서 좋은데
어떤 로직을 추가하거나 이런 부분이 필요한데 노드관련 설정을 좀 해야되는 것 같다.
예를 들어 게시글 수정,삭제 요청 시 비밀번호가 일치하는지 검증한다던가 이런걸 넣고
비밀번호가 틀렸을 때는 에러핸들링된 결과가 잘 나오는지 이런걸 보고싶은데 말이다.
생각해보니까 그런건 msw도 안되었던 것 같았다.
단순히 테스트코드에서 해당 api가 동작할 때 강제로 에러를 뱉게끔 다시 mocking하고
에러 alert가 뜨는지 안뜨는지 정도만 expect하는 식으로 했었던 기억이 있다.
