반응형

프로젝트들에 모노레포를 적용하면서 했던 의사결정과 pnpm에 대한 이모저모

 

모노레포 적용이 필요했던 배경

  • 멀티 레포로 관리되던 상황이었어서 공통의 util / 디자인 컴포넌트를 사용하기에 생각보다 큰 리소스가 예상되었다
  • 비즈니스의 흐름을 이해하기 어렵다
    • 피쳐 성격상 a웹과 b웹에서 같이 작업이 이루어지는 경우가 있을 수 있다
    • 이때 pr등에서 확인하기가 어렵고 여러 ide 창을 켜놔야 하는 경우도 있었다

=> 모노레포를 적용하고 이를 통해 위의 상황을 개선해보자!!


그래서 선택지는 총 3개

  • nx
  • pnpm
  • yarn berry

기존의 프로젝트 들은 yarn classic을 쓰고 있었다


처음 시도했던 것은 nx, 그러나

  • nx는 꽤나 어려웠다
  • 고점은 높아보였지만 러닝커브가 쉽지 않아 보였다
  • 회사 스테이지상 학습을 위한 시간을 확보하기는 매우 어렵다 <- 개인의 희생을 강요할 수 없다

이제 선택지는 yarn berry와 pnpm만 남았다

어찌할 것인가

 

pnpm을 선택하기로 했다

  • pnpm을 다뤄봤던 팀원이 있었고
  • npm trends를 믿어보기로 했다

 

(이 당시 잘못 알고 있었던 것은 yarn berry는 node_modules가 존재하지 않아 rn에서 쓸 수 없을까 였었다. 

yarn berry에서도 hoisted를 통해 node_modules를 생성할 수 있다)

 

pnpm은 빠르다

왜 빠른가

  • 설치시 pnpm store에 해당 라이브러리 들을 설치한다
  • a 프로젝트에서 라이브러리를 설치시 store로 부터 하드링크를 연결한다 <- 이미 설치되어 있다면 재설치를 하지 않는다 
  • node_modules/.pnpm에 store에서 가져온 라이브러리들이 존재한다
  • 비슷한 개념이 심링크 이다
    • 심링크는 바로가기로 연결만 한다
    • 이 심링크를 사용하는 것은 아래에서 확인하자
node_modules
├── foo -> ./.pnpm/foo@1.0.0/node_modules/foo
└── .pnpm
    ├── bar@1.0.0
    │   └── node_modules
    │       ├── bar -> <store>
    │       └── qar -> ../../qar@2.0.0/node_modules/qar <- /node_modules/.pnpm/qar@2.0.0/node_modules를 심링크
    ├── foo@1.0.0
    │   └── node_modules
    │       ├── foo -> <store>
    │       ├── bar -> ../../bar@1.0.0/node_modules/bar  <- /node_modules/.pnpm/bar@1.0.0/node_modules를 심링크
    │       └── qar -> ../../qar@2.0.0/node_modules/qar  <- /node_modules/.pnpm/qar@2.0.0/node_modules를 심링크
    └── qar@2.0.0
        └── node_modules
            └── qar -> <store>

 

 

1. 프로젝트에서 foo@1.0.0 라이브러리를 추가한다

2. node_modules/.pnpm에 foo@1.0.0이 하드링크로 추가된다 (이때 원본은 .pnpm의 store에 위치한다)

    * package를 import하는 방법을 정할 수 있는데 가장 권장되는 수단은 COW(CopyOnWrite) file system 이다

    * COW는 기본적으로 주소값 복사를 하고 변경이 필요한 경우 변경점만 별도로 디스크를 할당한다

3. foo@1.0.0의 내부서 의존하는 bar@1.0.0 / qar@2.0.0이 .pnpm에 하드링크로 추가된다 

4. foo@1.0.0의 내부 라이브러리들은 각 .pnpm에 설치된 라이브러리들에 심링크로 연결되어 있다 

5. foo@1.0.0은 프로젝트에서 직접 참조되므로 .pnpm의 외부로 이동된다. 이때 .pnpm을 심링크로 연결한다

 

COW(CopyOnWrite)

 

(npm은 캐싱 없이 매번 설치마다 node_modules에서 디스크 공간을 차지해야 한다)

 

 

그 외에 장점은

  • 유령 의존성을 없앤다
    • 패키지 별로 node_modules를 가지고 버전 명세가 명확하다
    • hoisting이 되지 않는 구조에서 package.json에 명세 없이 코드상에서 import를 하는 것은 실행이 되지 않는다
유령 의존성이란?

내 프로젝트에서 쓰고 있지만 package.json에는 없는 애


node_modules/
	lodash/
    a/package.json
    b/package.json/lodash



패키지 a의 코드에서
import lodash from 'lodash' <- 요 코드를 실행할 수 있다 (npm과 yarn classic에서는 실행가능)

=> 런타임에서 에러발생이 가능한 환경이 된다

 


rn에서 pnpm을 사용할 때 hoisting을 사용해야 한다

왜냐하면 rn의 하위 버전에서는 symlink가 동작하지 않고 메트로 + 기존 라이브러리에서 node_modules의 계층형 구조를 인식하지 못한다

빌드시 매번 node_modules에 라이브러리가 존재하지 않는다는 에러를 마주할 수 있다

아래와 같이 rn 하위버전 metro 설정에서 override를 해줘야 할 수 도 있다

metro.config.js

const defaultConfig = getDefaultConfig(projectRoot);
const {
  resolver: { sourceExts, assetExts },
} = defaultConfig;

function resolveFromProject(modulePath) {
  return path.dirname(require.resolve(`${modulePath}/package.json`, { paths: [projectRoot] }));
}

const reactDir = resolveFromProject('react');

const config = {
  resolver: {
    extraNodeModules: {
      react: reactDir,
    },
  },
};

module.exports = mergeConfig(defaultConfig, config);

 

but

 

store를 통한 의존성 설치시의 캐싱활용은 장점이 될 수 있다

유령의존성 제거 장점을 취하지 못한 것은 아쉬울 수 있다

ci/cd에서의 장점은 .pnpm store를 github에서 캐싱해둠으로써 매번 새로 설치하지 않아도 되는 장점을 이룰 수 있다

(아래는 캐싱 예시)

- name: Cache pnpm store
  uses: actions/cache@v3
  with:
    path: ~/.pnpm-store
    key: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}

 


 

.npmrc에서

node-linker를 hoisted로 설정할지 옵션을 설정할 수 있다

 

모노레포 프로젝트들의 버전을 override해줄 수 있다

이때 각 프로젝트의 node_modules에 라이브러리들이 설치가 된다

patch는 npm 환경에서 node_modules 내부 라이브러리를 직접 바꾸고 싶은경우 사용되는 방식이다

pnpm에서는 아래와 같이 설정할 수 있다

package.json

"pnpm": {
    "overrides": {
      "a>react": "19.0.0",
      "react": "18.2.0",
    },
    "patchedDependencies": {
      "c": "patches/c.patch",
      "d": "patches/d.patch",
    }
  },

 

root/
 ├─ apps/
 │   ├─ web/
 │   └─ admin/
 ├─ packages/
 │   ├─ ui/      (Shared Component Library)
 │   ├─ utils/   (Shared Business Logic)
 │   └─ config/  (ESLint, TSconfig shared)
 └─ pnpm-workspace.yaml

 

* apps는 실제 서비스이다

* packages는 공유 라이브러리 또는 컴포넌트 들이다

* pnpm은 내부 패키지에 대해서는 store를 거이지 않는다.

* pnpm은 내부 패키지들을 softlink 처리한다

* packages를 수정하면 바로 반영된다

 


 

pnpm의 선택은 단순 속도 문제는 아니었고

프로젝트 구조, 개발 경험(DX), 라이브러리의 선택 기준등 

생각보다 많은 것이 엮인 결정이었다.

728x90

'Frontend > React' 카테고리의 다른 글

Redux persist와 migration  (0) 2025.11.27
[번역] React Atomic하게 바라보기  (0) 2024.05.19
React patterns 🤔  (0) 2023.06.06
React 공식문서 주요개념 살펴보기  (1) 2022.05.26
React what is JSX? (번역글) 🤔  (2) 2022.04.27
반응형

개념

react 어플리케이션을 만들때면 전역 상태 관리를 위해 redux를 사용해야 할 때가 있습니다

 

이 전역상태 역시 메모리 상의 상태이기 때문에, 페이지를 새로고침 하거나 앱 프로세스가 초기화되면 전부 초기화 됩니다.

이렇게 되면 로그인이 풀려버리는 등의 상황을 마주할 수 있어요

그렇지 않기 위해서

웹에서는 localStorage, sessionStorage, cookie등 브라우저 스토리지에 이를 저장해두고 동기화를 하여 사용하거나

react-native에서는 fileSystem 혹은 asyncStorage에 저장을 해두어 새로고침이나 앱 종료 후에도 상태를 유지할 수 있습니다.

 

이 과정을 도와주는 라이브러리가 redux-persist 입니다

redux-persist에서는  stoarge engines을 변경함으로써 다양한 환경에서 redux의 값을 저장해줄 수 있습니다

가령 아래와 같은 방식입니다.

// 예시를 위해 몸을 심하게 비튼 코드

const getStorage = () => {
  switch(환경) {
  	case 일렉트론
    	return createElectronStorage()
    case 웹 로컬 스토리지
        return localStorage // import storage from 'redux-persist/lib/storage'
    case 웹 세션 스토리지 
    	return sessionStorage // import storage from 'redux-persist/lib/storage/session'
    case 리액트 네이티브
    	return asyncStorage // import storage from '@react-native-community/async-storage';
    등등
  }
}


const persistConfig = {
	key: 'root',
    storage: getStorage() // 이곳의 storage만 바꿔준다면 다양한 환경에서 사용가능
};

const persistedReducer = persistReducer(persistConfig, rootReducer)

 

이렇게 사용을 할 때 주의해야 하는 점이 있습니다

스토리지에 저장된 값의 구조(타입)과 현재 코드에서 사용되는 형태가 달라지게 된다면 어떻게 될까요?

상황에 따라 브라우저에서는 런타임에러가 발생할 수 있고 

앱에서는 앱의 크래시가 발생할 수 있습니다

 

이러한 상황을 막기 위해 migration을 적절히 해주어야 합니다

이 글에서는 실무에서 migration을 적용하여 기존의 버그들을 피한 상황을 서술하려 합니다

 

실무에서 발생했던 상황은 아래와 같습니다.

redux의 값을 수정했고 코드푸시를 나간이후에 기존 유저의 앱에서 crash가 나는 현상이 발생되었다

 


코드 예시

에러가 나는 상황

기존에 redux-persist를 통해 값이 저장되어 있던 형태

type TodoState = string[] // ['밥먹기', '출근하기']


const todoPersistConfig = {
  key: 'todo',
  storage,
};


const rootReducer = combineReducers({
  todos: persistReducer(todoPersisConfig, todo),
});

 

값을 가져와서 쓰던 형태

const todos = useSelector((state) => state.todos);

return (
  <View>
  	{todos.map((todo) => (
      <Text>{todo}</Text>
    )}
  </View>
)

 

값이 저장되어 있던 형태가 변경되었고 이것이 코드푸시를 통해 배포가 나감

type Todo = { id: number, title: string };

type TodoState = {
  list: Todo[];
}

const todoPersistConfig = {
  key: 'todos',
  storage,
};


const rootReducer = combineReducers({
  todos: persistReducer(todoPersisConfig, todo),
});

 

이때 마이그레이션을 하지 않으면 런타임에서 에러가 발생 

const { list: todos } = useSelector((state) => state.todos);  // <- redux-persist를 통해 storage에
// 저장되어 있던 값은 ['밥먹기', '출근하기']
// list가 존재하지 않음
// 아래 런타임에서 에러 발생

return (
  <View>
  	{todos.map((todo) => (
      <Text>{todo.title}</Text>
    )}
  </View>
)

 

새로운 유저는 영향 x, 기존에 redux에 값이 저장되어 있던 유저만 영향을 받는 상황

=> qa를 어렵게 하고 예측 불가능한 상황이 되어 버림

 위와 같은 이유로 안쓰는 키값을 제거하거나 타입의 변경시 에러 방지를 위해 마이그레이션이 필요합니다

 


마이그레이션 방법

persistConfig를 정의할때 migration이 필요할 경우 migration 코드와 version을 올려주면 됩니다

import { createMigrate } from 'redux-persist'

const migrations = {
  1: (state) => {
  	if (state && typeof state === 'object') {
      return {
        ...state,
        todo: { 
        	list: []
        }
      };
    }
  } 
}


const persistConfig = {
  key: 'root',
  storage,
  version: 1, // 버전을 1로 증가하여 새로운 마이그레이션 트리거
  migrate: createMigrate(migrations, { debug: __DEV__ }),
};

 

 

728x90

'Frontend > React' 카테고리의 다른 글

pnpm과 이모저모  (0) 2025.11.27
[번역] React Atomic하게 바라보기  (0) 2024.05.19
React patterns 🤔  (0) 2023.06.06
React 공식문서 주요개념 살펴보기  (1) 2022.05.26
React what is JSX? (번역글) 🤔  (2) 2022.04.27
반응형

Atomic Design, by Brad Frost

 

Brad Frost의 아토믹 디자인 원칙에 익숙하지 않다면 잠시 멈추고 그의 블로그 혹은 그의 책을 읽어보세요. 근사한 디자인 시스템이고 적절히 수행되었을때 여러분 어플리케이션의 화면 구성요소들이 아름답고 간편하게 구성될 수 있습니다.


 

아토믹 디자인이 간단하게 말해서 무엇인가요?

아토믹 디자인은 사용자 인터페이스를 더 작고 단순한 요소들로 분리하는 개념입니다. 아토믹 디자인에는 다섯개의 각기 다른 레벨이 존재합니다. atoms, molecules, organism, templates, pages.

하나의 atom은 input 필드 혹은 버튼이 될 수 있습니다. 이러한 atom들은 검색 molecule을 만들기 위해 로고 atom들과 결합되어 질 수 있고 navbar organism을 만들기 위한 네비게이션 molecule을 구성할 수 있습니다.

 

atom, molecule, organism들을 사용하여 page를 위한 template을 구성할 수 있고 디자인 process를 더 빠르게 만들 수 있습니다


 

이게 어떻게 React와 잘 맞을 수 있을까?

1년 반정도 React를 빡세게 다뤄왔습니다. 그 당시 나는 아키텍쳐 실수들을 공유해왔고 다른 사람들의 실수를 보면서 배워왔습니다.

React는 KISS(Keep it simple, stupid)를 정말 추구하고 '한 가지 일만 잘하게 해라'와 같은 것들을 배웠습니다.

React 어플리케이션을 architecting할때 아토믹 디자인 패턴을 따르는 이러한 방법론을 따르는 것을 보장합니다.

 

Atom으로서의 단순한 컴포넌트들

컴포넌트들은 가능하면 바보여야 합니다. 어플리케이션의 비즈니스 로직에 대해서는 알지 못해야 하고 그들이 의미하는 것은 단순히 보여주는 것이어야 합니다.

Three distinct atoms, that when combined, can make a search molecule

 

우리가 Button 컴포넌트를 만들고 있다고 해봅시다. Button은 label을 가져야 하고 type, onClick 핸들러도 가져야 할 겁니다.

버튼은 디자인 된대로 보여지게 지게 되고 onClick을 다루게 됩니다.

onClick이 발생했을 때 API 호출을 다루지 않아야 합니다. 그게 이 container의 역할 이빈다.

 

This is what makes it an atom. It’s a small, contained, and simple component of our application.

 

React에서의 Molecules 

TextInput 컴포넌트와 Button 컴포넌트로 검색 모듈을 만들어야 한다고 해보겠습니다. 두개의 컴포넌트들을 결합할때 molecule로서 동작하는 검색 컴포넌트를 만들 수 있습니다. 만약 가능하다면 atom과 같이 molecule에서도 비즈니스 로직에 대해 몰라야 합니다. 버튼 컴포넌트가 눌러졌을때 onSearchClick 핸들러를 가질 수 있지만 TextInput 컴포넌트에 어떤게 입력되었는지에 따라 어떠한 결과라도 fetch하지 않아야 합니다. 이것이 컨테이너의 역할 입니다.

 

Search Molecule

 

Organimsms, Everywhere

Organism은 page들을 그룹핑하기 위해 사용되는 복잡한 Ui 구성요소들과 더 유사합니다. 그들이 molecule과 atom보다 더 복잡하기 때문에 organism들을 비즈니스 로직들을 처리해야 할 수 있습니다.

 

이커머스 웹사이트와 상품 페이지가 있다고 가정해볼게요. Navbar organism과 상품 molecule를 가지고 있는 ProductGrid organism으로 만들어졌습니다. 아래의 Navbar organism을 보시죠

Navbar Organism

 

 

Navbar Organism은 이전에 만든 Search molecule, Navigation molecule, Logo atom으로 만들어졌습니다. 이러한 경우 organism은 비즈니스 로직을 처리할 필요가 없습니다. Organism이 구성될 때 template과 page들에서 비즈니스 로직들을 다룰 수 있도록 만들 수 있습니다

 

컨테이너들은 Template/Page들과 같아야 하나요?

맞습니다. Container는 organism, molecule, atom들을 가지고 있고 복잡한 로직들을 다룹니다. Template과 Page는 또한 organism, molecule, atom들을 가집니다. 작은 컴포넌트 요소들을 결합하면 어플리케이션의 interface를 만들수 있습니다.

 

A template, which can be turned into a page

 

그래서 어느 Atomic 단계에서 비즈니스 로직을 다뤄야 하는데?

organism을 가지게 되면 상황은 조금 더 복잡해 집니다. 위에서 언급한 이커머스 상품 페이지에서 Navbar organism은 비즈니스 로직을 수행할 필요가 없지만 ProductGrid organism은 만약 우리가 paginate를 해야한다면 상품 fetch역할을 요구받게 됩니다. 상품에 대해 구체적인 파라미터들을 추가할 수있고 추가한 파라미터들을 가지고 API호출을 하는 Filter organism도 있을 수 있습니다.

 

사용자 interface를 더 작은 atom, molecule, organism으로 쪼개면 비즈니스 로직을 가지지 않게 할 수 있습니다. Hoc는 atomic 단계에서 필요한 데이터를 내려주고 api 호출들을 다룰 수 있습니다

 

가끔, orgnism, molecule에서 api 혹은 비즈니스 로직에 접근해야 할 수 있습니다. 당연한 일입니다. 하지만 컴포넌트 내부의 코드가 너무나도 복잡해진다면 무엇인가 잘못된 것입니다


결론

React 에서 Atomic 디자인을 따르는 것은 본질적으로 개발자들에게 컴포넌트를 단순하고 작게 쪼갤 수 있게 해줍니다.

이러한 단순성으로부터 우리는 더 복잡한 컴포넌트드로가 사용자 인터페이스를 구성하는 컨테이너 컴포넌트들을 만들 수 있습니다.

이러한 패턴을 따르는 것은 React 어플리케이션들을 다루기 쉽게 해줍니디ㅏ.

 

보너스: 파일들을 Atomic Design에 맞게 구성하세요

위의 방법론을 atoms/, molecules/, organisms/, templates/, pages/와 같이 파일을 구성하는데도 사용할 수 있습니다. 

start kit 중 Atomic React 는 좋은 예시입니다. Personally, I like a little bit of a mix of things and have written an article about folder structure in React, but its definitely an option for you 

 

 

 

 

 

출처 : https://medium.com/@wheeler.katia/thinking-about-react-atomically-608c865d2262

 

Thinking About React, Atomically ⚛

Utilizing Brad Frost’s Atomic Design principles to better architect React applications

medium.com

 

728x90

'Frontend > React' 카테고리의 다른 글

pnpm과 이모저모  (0) 2025.11.27
Redux persist와 migration  (0) 2025.11.27
React patterns 🤔  (0) 2023.06.06
React 공식문서 주요개념 살펴보기  (1) 2022.05.26
React what is JSX? (번역글) 🤔  (2) 2022.04.27
반응형

아래 출처의 글을 보고 번역 및 주요 내용을 정리한 글입니다. 

 

  • 어떻게 하면 다양한 경우에 적합한 재사용 가능한 컴포넌트를 build할 수 있을까?
  •  어떻게 하면 사용하기 쉽게 단순한 API와 컴포넌트를 만들 수 있을까?
  • 어떻게 하면 UI와 기능적으로 확장 가능한 컴포넌트를 만들 수 있을까??

에 대한 고민으로 이 글은 시작합니다.

 

5가지의 패턴을 제시하고 장점, 단점을 리스트업 해줍니다.

그리고 두개의 기준을 명시해 주었습니다.

  • 제어의 역전 : 컴포넌트를 사용하는 사람들에게 제공되는 유연성과 주도권의 정도
  • 구현의 복잡도 : 해당 패턴을 구현하는데 복잡도

1.  Compound Components Pattern

이 패턴은 prop drilling을 피하면서 선언적으로 컴포넌트를 구성할 수 있게 해줍니다. 이해가 쉬운 api와 관심사의 더 나은 분리와 함께, customizable 컴포넌트를 만들고 싶다면 이 패턴을 고려하세요

 

장점

* api의 복잡도 감소: 거대한 부모 컴포넌트에 props들을 묶어서 보내지 않고 자식 ui 컴포넌트에 prop drilling을 피할 수 있ㄷ습니다. 대신 Counter's의 자식들에 prop들이 매칭되므로 더 이해하기 쉽습니다

* 유연한 마크업 구조: 다양한 경우의 대응과 함께 좋은 ui 유연성을 제공하빈다. 예를 들면, Counter's의 자식들의 순서를 쉽게 변경하거나 어떻게 보일것인지를 결정할 수 있습니다.

* 관심사의 분리: 대부분의 로직은 Counter에 집중됩니다. 하나의 context(CounterProvider + useCounterContext)가 Counters' 자식들에게 상태(counter)와 handler(handleIncrement(), handleDecrement())를 다루기 위해 사용됩니다.

책임의 분배를 더 명확히 해줍니다.

단점

* 너무 높은 ui 유연성 : 이 정도의 유연성은 애초에 기대하지 않았던 상황을 초래할 수 있습니다(i.e: 원하지 않던 코드, Counter's 자식들의 잘못된 순서, 필수 자식들의 실종). 상황에 따라 너무 많은 유연성을 원하지 않을 수 있습니다.

 

* 비대해진 JSX: jsx의 크기를 증가시킵니다. eslint를 쓰거나 prettier를 쓰면 더더욱 그러할 것입니다. 하나의 컴포넌트에서는 미미해보일 수 있지만, 전체 큰 그림에서 보게되면 큰 차이가 있을 수 있습니다

기준

* 제어의 역전 : 1/4

* 구현의 복잡도 : 1/4

 

이 패턴을 사용하는 라이브러리

* React Bootstrap

* Reach ui

2. Control Props Pattern

* 이 패턴은 컴포넌트를 제어 컴포넌트로 만듭니다. 외부 상태는 컴포넌트의 기본 동작을 수정할 수 있는 로직을 넣을 수 있는 "single source of truth"로 동작합니다.

 

장점

* 더 많은 제어권: 개발자가 주요 상태를 제어할 수 있기 때문에, Counter의 동작에 직접 영향을 줄 수 있습니다.

단점

* 구현의 복잡도: 이전에는 하나의 통합된 부분으로 컴포넌트의 동작이 충분했습니다. 이제는 3개의 다른 부분이 존재 합니다.

 

기준

* 제어의 역전: 2/4

* 구현의 복잡도: 1/4

 

이 패턴을 사용하는 라이브러리

* Material UI

 

3. Custom hook Pattern

* 제어의 역전에서 나아가 보자: 주요 로직은 커스텀 훅 내부에 위치합니다. 이 훅은 몇몇 내부 로직으로 구성되어있고 개발자에게 좋은 제어권을 제공합니다.

 

장점

* 더 많은 제어권: 개발자는 Counter 동작을 수정하면서, useCounter와 Counter 사이에 커스텀 로직을 더 부여할 수 있습니다. 

 

 

단점 

* 구현의 복잡도: 로직 부분이 render 부분과 분리되었기 때문에 개발자는 두 군데를 신경써야 합니다. Counter가 어떻게 동작하는지 잘 이해하는 것이 이 패턴을 수행하기 위해 필수 입니다.

 

 

기준 

* 제어의 역전 : 2/4

* 구현의 복잡도 : 2/4

 

이 패턴을 사용하는 라이브러리

* React table

* React hook form

 

 

4. Props Getters Pattern

* Custom Hook Pattern은 더 나은 제어권을 제공하지만 로직을 재생성해야 하고 원래 hook의 props를 다루어야 하기 때문에 컴포넌트의 통합을 어렵게 합니다.

Props Getters Pattern 패턴은 이러한 복잡도를 다루기 위해 시도합니다. props들을 노출시키는 대신에 getters들을 제공합니다.

getter은 많은 prop들을 반환하는 함수 입니다. 의미있는 이름을 가지고 있고 jsx 요소에 어떤것이 대응하는지 명확히 할 수 있습니다.

 

장점

* 쉬운 사용: 복잡도는 숨겨져 있습니다. useCounter에서 제공하는 getter를 jsx 요소에 알맞게 연결하기만 하면 됩니다.

* 유연성: getter를 특별한 경우에 오버로딩 할 수 있습니다.

 

단점

* 가독성의 저하: getters는 컴포넌트를 통합하기 수월하게 하는 추상화를 제공해 주지만 좀 더 모호합니다. 개발자는 getter props들을 잘 이해하고 있어야 하고 영향 받는 로직들을 오버라이드 하기 위해 적절히 이해하고 있어야 합니다.

 

기준

* 제어의 역전: 3/4

* 구현 복잡도: 3/4

 

이 패턴을 사용하는 라이브러리

* React table

* Downshift

 

 

5. State reducer Pattern

제어의 역전에서 가장 발전된 패턴이빈다. 컴포넌트가 내부적으로 컴포넌트가 작동하는 방식을 변경할 수 있는 더 나은 방법을 제공합니다. Custom Hook Pattern과 유사하지만 hook을 위해 reducer를 제공해야 합니다. 이 reducer는 컴포넌트의 어떠한 내부 동작이라도 오버로드 할 수 있습니다.

 

장점

* 더 많은 제어권 : 복잡한 경우 state reducer의 사용이 개발자에게 제어권을 주기 가장 좋은 방법입니다. useCounter's의 모든 내부 동작은 밖에서 접근이 가능하고 override될 수 있습니다.

 

단점

* 구현의 복잡도: 이 패턴은 구현하기 가장 복잡합니다

* 가독성의 저하: reducer의 내부 동작이 변경될 수 있기 때문에 컴포넌트 내부 로직의 높은 이해가 필수 입니다.

 

기준 

* 제어의 역전: 4/4

* 구현 복잡도: 4/4

 

이 패턴을 사용하는 라이브러리

* Downshift

 

결론

* 5개의 React 패턴들을 통해 제어의 역전 측면에서 이점을 가지는 방법들을 살펴 보았습니다. 유연하고 확장가능한 컴포넌트를 만드는 강력한 방법들을 제공합니다.

그러나, "큰 힘에는 큰 책임이 따른다"라고 알고 있듯이, 개발자에게 더 많은 제어권이 주어지면, "plug and play" 방식에서 컴포넌트는 더 멀어질 수 있습니다. 이것이 적절한 패턴을 적절한 경우에 사용하여야 하는 이유입니다.

 

아래의 그림은 제어의 역전과 구현 복잡도에 따라 패턴을 분류한 그림입니다.

 

 

 

 


 

출처: https://javascript.plainenglish.io/5-advanced-react-patterns-a6b7624267a6

 

5 Advanced React Patterns

An overview of 5 modern advanced React patterns, including integration codes, pros and cons, and concrete usage within public libraries.

javascript.plainenglish.io

 

728x90
반응형

3. 엘리먼트 렌더링

React에서 엘리먼트는 최소 단위 입니다.

이런 엘리먼트가 모여서 컴포넌트를 이루고 컴포넌트들이 모여서 프로덕트가 완성됩니다.

엘리먼트는 화면에 표시해줄 내용을 가지고 있습니다.

const element = <h1>Hello, world</h1>;

이러한 엘리먼트를 화면에 렌더링하려면 ReactDOM.render()를 이용하면 됩니다.

ReactDOM.render에는 엘리먼트와 루트 DOM 노드가 들어가게 됩니다.

<div id="root"></div>


const element = <h1>Hello, world</h1>
ReactDOM.render(element, document.getElementById('root'))

// ReactDOM.render(엘리먼트, 루트 DOM 요소)

React에서 엘리먼트는 불변객체 입니다. (엘리먼트가 생성된 이후에 자식이나 속성을 변경한다든가 하는 동작이 불가능!!!)

엘리먼트를 갱신하는 방법은 새로운 엘리먼트를 생성하고 이를 ReactDOM.render로 전달하는 방법 뿐입니다.

 

function tick() {
  const element = <h1>Hello, world</h1>
  
  ReactDOM.render(element, document.getElementById("root"))
}

setInterval(tick, 1000);

 

이렇게 매번 엘리먼트가 갱신이 되면 효율적으로 렌더링 하기 위하여

가상 DOM과 실제 DOM을 비교하여 변경된 부분만 실제 업데이트를 하게 됩니다.

가상 DOM의 재조정 알고리즘은 추후에 다뤄볼 수 있도록 하겠습니다.

아래 이미지는 엘리먼트가 매번 바뀌지만 전체가 변경되는 것이 아닌 내용이 변경된 텍스트 노드만 업데이트 되는 모습입니다.

 

 

 


4.  Component와 Props

props는 속성을 나타내는 데이터입니다.

컴포넌트는 함수형 컴포넌트와 클래스형 컴포넌트로 나뉘어 집니다.

const test = () => {
  return <h1>hihi</h1>;
}

위의 예시는 함수형 컴포넌트

class Test extends React.Component {
  render() {
    return <h1>hihi</h1>
  }
}

위의 예시는 클래스형 컴포넌트 입니다.

 

클래스형 컴포넌트는 훅의 등장 이후에는 널리 사용되지 않는걸로 알고 있습니다.

 

훅은 아래와 같은 이유로 등장을 하였습니다.  

컴포넌트에서 상태로직을 재사용하기 위해

클래스형 컴포넌트의 this는 혼잡을 가져왔고,

componentDidUpdate, componentDidMount와 같이 lifecycle에 중복되는 메서드들이 위치되어 지는 상황을 위해

 

아래의 예시부터는 함수형 컴포넌트를 기준으로 다루게 됩니다.

 

function Welcome(props) {
  return <h1>Hello, {props.name}</h1>
}

const element = <Welcome name="Sara" />
ReactDOM.render(
  element,
  document.getElementById('root')
)

 

1. ReactDOM.render에서 Welcome 컴포넌트를 호출합니다.

2. Welcome 컴포넌트에 props로 name이 넘어갑니다.

3. Welcome 컴포넌트는 <h1>Hello, sara</h1>를 호출합니다.

4. ReactDOM은 <h1>Hello, Sara</h1>엘리먼트와 일치하도록 DOM을 효율적으로 업데이트 합니다(가상돔 개념)

 

 

!!! React 에서 커포넌트 이름은 항상 대문자여야 합니다. 소문자로 작성하게 되면 html 태그로 인식하게 됩니다.

 

 

컴포넌트 합성

여러 컴포넌트를 합성하여 하나의 컴포넌트를 만들 수 있습니다

function Welcome (props) {
  return <h1>hihi</h1>
}

function App() {
  return (
    <Welcome />
    <Welcome />
    <Welcome />
  )
}

 

컴포넌트 추출

function Comment(props) {
  return (
    <div className="Comment">
      <div className="UserInfo">
        <img className="Avatar"
          src={props.author.avatarUrl}
          alt={props.author.name}
        />
        <div className="UserInfo-name">
          {props.author.name}
        </div>
      </div>
      <div className="Comment-text">
        {props.text}
      </div>
      <div className="Comment-date">
        {formatDate(props.date)}
      </div>
    </div>
  );
}

위의 컴포넌트를 아래의 여러 컴포넌트로 추출할 수 있습니다.

 

function Comment(props) {
  return (
    <div className="Comment">
      <UserInfo author={props.author} />
      <div className="Comment-text">
        {props.text}
      </div>
      <div className="Comment-date">
        {formatDate(props.date)}
      </div>
    </div>
  );
}

function UserInfo(props){
  <div className="UserInfo">
  	<Avatar user={props.author} />
    <div className="UserInfo-name">
      {props.author.name}
    </div>
  </div>
}

function Avatar(props) {
	<img className="Avatar"
      src={props.user.avatarUrl}
      alt={props.user.name}
    />
}

 

!!!! props의 이름은 사용될 context가 아닌 컴포넌트 자체의 관점에서 짓는 것을 권장합니다!!

=> 컴포넌트는 재사용될 수 있으므로 컴포넌트 자체의 관점에서 바라보는 것이 좋다고 생각합니다.

context의 관점에서 props의 이름을 설정하면 재사용 했을때 새로운 context의 이해관계와 충돌이 날 수 있다고 생각합니다.

 

Props는 읽기 전용입니다!

모든 react 컴포넌트는 자신의 Props를 다룰 때 반드시 순수 함수처럼 동작해야 합니다!!

순수함수란 동일한 입력값에 항상 동일한 결과를 반환하는 특성을 가지고 있습니다.

 


5. State와 생명주기

function Clock(props) {
  return (
    <div>
      <h1>Hello, World</h1>
      <h2>It is {props.date.toLocaleTimeString()}</h2>
    </div>
  )
}

function tick() {
  ReactDOM.render(
    <Clock date={new Date()} />,
    document.getElemnetById("root")
  )
}

setInterval(tick, 1000)

 

props를 외부에서 주입하지 않고 state에서 new Date() 값을 가지게 하였습니다.

저는 위의 함수를 아래와 같은 함수형 컴포넌트로 변경하였습니다.

 

function Clock() {
  const [date, setDate] = useState(new Date())
  useEffect(() => {
    const tick = setInterval(() => setDate(new Date()), 1000)  
    return () => clearInterval(tick)
  }, []);

  return (
    <div>
      <h1>Hello, World</h1>
      <h2>It is {date.toLocaleTimeString()}</h2>
    </div>
  );
}


ReactDOM.render(<Clock />, document.getElementById("root"));

 

위의 date는 커스텀 훅으로 뺄 수도 있을 것 같습니다! 재사용이 필요하다면 이동하여 위치 시킬 수 있습니다.

state는 props와 유사하지만, 비공개이며 컴포넌트에 의해 완전히 제어됩니다.

 


6. 이벤트 처리하기

react에서 이벤트는 소문자 대신 카멜케이스를 사용합니다.

<button onClick={activateLasers}>
  Activate Lasers
</button>

 

새로 알게된 내용 

=> react에서는 Return false를 반환해도 기본 동작을 반환할 수 없습니다.

html에서는 가능합니다.

<form onsubmit="console.log('You clicked submit.'); return false">
  <button type="submit">Submit</button>
</form>
const Form = () => {
  function handleSubmit(e) {
    e.preventDefault();
    console.log('You Clicked submit.');
  }
  
  return (
    <form onSubmit={handleSubmit}>
    	<button type="submit">Submit</button>
    </form>
  )

}

 


7. 조건부 렌더링

React에서는 조건부 렌더링을 수행할 수 있습니다.

상황에 따라 로그인 컴포넌트나 로그아웃 컴포넌트를 리턴해 줄 수 있습니다.

 

아래와 같은 경우 Props로 전달받은 isLogin에 따라 LogoutComponent, LoginComponent를 리턴해 줄 수 있습니다.

const Component = ({ isLogin }) => {   
   if(isLogin) {
     return <LogoutComponent />
   }
   
   return <LoginComponent />
}

 

 

저는 주로 Early return을 사용하거나 return문 내에서 논리연산자를 활용하여 컴포넌트를 뱉어냅니다.

const Component = ({ isLogin }) => {      
   return (
   	<div>
    	{isLogin && <LogoutComponent />}
        {!isLogin && <LoginComponent />}
    </div>
   )
}

 

삼항연산자도 사용할 수 있습니다.

const Component = ({ isLogin }) => {      
   return (
   	<div>
    	{isLogin ? <LogoutComponent /> : <LoginComponent />}
    </div>
   )
}

 


8. 리스트와 key

리액트에서는 리스트 컴포넌트를 표현할 수 있습니다

const numbers = [1,2,3,4,5]
const Items = () => {
  return (
  {numbers.map(number => <div>{number}</div>)}
  )
}


ReactDOM.render(<Items />, document.getElementById('root'))

위의 코드는 리액트에서 리스트를 표현하는 대표적인 방식입니다.

 

이때, key를 넣어주어야 합니다.

리액트에서는 같은 레벨의 자식들 간에는 Key값을 이용하여 재조정 해야할지 말지를 판단하기 때문입니다.

const numbers = [1,2,3,4,5]
const Items = () => {
  return (
  {numbers.map(number => <div key={number.toString()}>{number}</div>)}
  )
}


ReactDOM.render(<Items />, document.getElementById('root'))

 

같은 형제 노드들에서 값이 변하지 않았다면 key 값으로 판단하여 리렌더링을 하지 않습니다.

가령 index를 key값으로 사용하는 경우가 있습니다.

이러한 경우에는 비효율적인 리렌더링이 발생할 수 있습니다.

 

아래의 경우는 맨 끝에 5가 포함된 모습입니다.

이러한 경우에는 1,2,3의 리렌더링이 발생하지 않습니다.

React에서는 Key를 통해 항목의 순서가 변경되지 않았다는 것을 알 수 있으니까요

<div key={1}>1</div>
<div key={2}>2</div>
<div key={3}>3</div>

<div key={1}>1</div>
<div key={2}>2</div>
<div key={3}>3</div>
<div key={4}>5</div>

 

아래의 경우는 4가 1앞에 추가된 모습입니다.

key값은 바뀌지 않았지만 값의 변화가 생긴것을 볼 수 있습니다.

모든 요소들의 Key값이 변경된 모습을 확인할 수 있습니다.

react에서는 같은 자식레벨에서 key를 통해 기존 트리와 이후 트리가 일치하는 지 확인합니다.

 

인덱스를 key로 사용하면 항목의 순서가 바뀌었을때 key값이 변경될 수 도 있습니다.

input을 체크했는데 key값이 변경되면 label만 변경된다 거나 하는 의도치 않은 상황을 맞이할 수 도 있습니다.

(React에서는 동일한 key값에 같은 DOM 요소를 보여줍니다)

<div key={1}>1</div>
<div key={2}>2</div>
<div key={3}>3</div>

<div key={1}>4</div>
<div key={2}>1</div>
<div key={3}>2</div>
<div key={4}>3</div>

 


9. 폼

html에서 input, select, textarea와 같은 폼 엘리먼트는 사용자의 입력을 기반으로 자신의 state를 가지게 됩니다.

React에서는 컴포넌트에서 state를 가지게 됩니다. state를 input, select, textarea에 value 속성으로 전달함으로써 제어컴포넌트로 관리할 수 있습니다.

값이 바뀔때마다 컴포넌트가 리렌더링 된다는 (상태가 변경되기 때문에) 단점이 있지만 편리함때문에 비제어 컴포넌트와 잘 고려하여 사용을 하는게 좋을듯 합니다.

cpu의 성능까지 고려하면 더 좋을듯 하구여

 

return (
  <form onSubmit={this.handleSubmit}>
    <label>
      Name:
      <input type="text" value={this.state.value} onChange={this.handleChange} />
    </label>
    <input type="submit" value="Submit" />
  </form>
);

return (
  <form onSubmit={this.handleSubmit}>
    <label>
      Essay:
      <textarea value={this.state.value} onChange={this.handleChange} />
    </label>
    <input type="submit" value="Submit" />
  </form>
);
    

return (
  <form onSubmit={this.handleSubmit}>
    <label>
      Pick your favorite flavor:
      <select value={this.state.value} onChange={this.handleChange}>
        <option value="grapefruit">Grapefruit</option>
        <option value="lime">Lime</option>
        <option value="coconut">Coconut</option>
        <option value="mango">Mango</option>
      </select>
    </label>
    <input type="submit" value="Submit" />
  </form>
);

 


10. State 끌어올리기

 

state 끌어올리기는 컴포넌트 내부에서 관리되던 상태를 공통으로 사용해야 하는 컴포넌트와의 가장 가까운 공통 부모로 이동시키는 것을 의미합니다.

 

리액트 공식문서에서는 온도를 화씨와 섭씨로 변경하여 보여주는 부분을 예시로 보여주었습니다.

class Calculator extends React.Component {
  constructor(props) {
    super(props);
    this.handleCelsiusChange = this.handleCelsiusChange.bind(this);
    this.handleFahrenheitChange = this.handleFahrenheitChange.bind(this);
    this.state = {temperature: '', scale: 'c'};
  }

  handleCelsiusChange(temperature) {
    this.setState({scale: 'c', temperature});
  }

  handleFahrenheitChange(temperature) {
    this.setState({scale: 'f', temperature});
  }

  render() {
    const scale = this.state.scale;
    const temperature = this.state.temperature;
    const celsius = scale === 'f' ? tryConvert(temperature, toCelsius) : temperature;
    const fahrenheit = scale === 'c' ? tryConvert(temperature, toFahrenheit) : temperature;

    return (
      <div>
        <TemperatureInput
          scale="c"
          temperature={celsius}
          onTemperatureChange={this.handleCelsiusChange} />
        <TemperatureInput
          scale="f"
          temperature={fahrenheit}
          onTemperatureChange={this.handleFahrenheitChange} />
        <BoilingVerdict
          celsius={parseFloat(celsius)} />
      </div>
    );
  }
}

 

 

이는 제가 의식하고 사용하려고 하는 방식중 하나입니다.

제가 상태를 관리하는 원칙은 다음과 같습니다. 

이러한 근거는 상태는 이용되는 컴포넌트와 가까운 위치에 정의되어 있어야 한다는 기조에 근거합니다.

1. 상태는 사용하는 컴포넌트에서 관리

2. 같은 상태를 공유해야하는 컴포넌트와 가장 가까운 부모 컴포넌트에 상태를 이동 (상태 끌어올리기 사용)

3. 거리가 너무 멀다면 contextAPI 적용 

4. Redux나 Recoil 적용 검토

 

상태와 컴포넌트간의 거리가 너무 멀다면 props drilling이 발생하고 코드의 흐름을 파악하기 어려워 집니다.

또한 불필요한 리렌더링이 발생할 수 있으므로 위와 같은 방식을 저는 선호합니다.

그중 첫단계인 상태 끌어올리기에 관한 내용이 10장 이었습니다.

728x90
반응형

이 글은 아래 출처의 글을 번역한 글입니다. 오역과 의역을 자주 사용합니다.

 

글 상단의 강의 영상들은 가져오지 못했습니다.
embed 되어있는 강의 영상 자체는 가져올 수 있는데 사이트에 css가 tailwind로 적용되어있어 overhead가 커질것 같아 가져오지 않았습니다.

 

이제 블로그 포스트로 넘어가겠습니다.

 

React를 효과적으로 사용하는 방법을 이해하는데 있어 중요한 부분은 자바스크립트와 자바스크립트 표식을 이해하는 것이라 생각합니다. 그래서 JSX의 일부 예제를 보여드릴거고 JSX가 컴파일된 버전은 어떻게 동작하는지 도움을 줄것 입니다. 머릿속에서 JSX를 컴파일 할 수 있다면 추상화를 좀 더 강력하게 사용할 수 있습니다.

 

간단한 예시가 있습니다.

모든 예제들은 변수에 할당할 수 있는 정규 Javascript 표현식임을 나타내기 위해  변수 `ui`에 할당됩니다.
ui = <div id="root">Hello world</div>
ui = React.createElement('div', {id: 'root'}, 'Hello world')

 

위에서 볼 수 있듯이 jsx는 `React.createElement`로 컴파일 됩니다. `React.createElement` API는 아래와 같습니다

function createElement(elementType, props, ...children) {}

 

  • `elementType` 는 문자열이나 생성되어지는 요소의 타입을 위한 함수일 수 있습니다
  • `props`는 요소에 적용하기 위한 props 객체 입니다. (`null` 값이 들어올 수도 있습니다)
  • `...children`는 요소에 적용하고 싶은 모든 자식들 입니다. 편의상 위와 같이 나와있고 위와 동일하게 아래와 같이도 사용할 수 있습니다
ui = React.createElement('div', {id: 'root', children: 'Hello world'})

 

만약 당신이 하나 이상의 자식을 가지고 있다면 배열을 사용할 수 있습니다.

 

ui = (
  <div>
    <span>Hello</span> <span>World</span>
  </div>
)
ui = React.createElement('div', {
  children: [
    React.createElement('span', null, 'Hello'),
    ' ',
    React.createElement('span', null, 'World'),
  ],
})

// Note: babel uses the third argument for children:
ui = React.createElement(
  'div', // type
  null, // props
  // children are the rest:
  React.createElement('span', null, 'Hello'),
  ' ',
  React.createElement('span', null, 'World'),
)

 

`React.createElement` 를 호출하면 단순한 객체를 얻을 수 있습니다.

 

// <div id="root">Hello world</div>
{
  type: "div",
  key: null,
  ref: null,
  props: { id: "root", children: "Hello world" },
  _owner: null,
  _store: {}
};

 

이러한 객체를 `ReactDOM.render`나 다른 렌더에 전달해 주면 element 객체를 해석하고 DOM node를 생성하는 것이 렌더러의 작업입니다. 깔끔하죠?

 

아래에 당신을 위한 더 많은 예시가 있습니다

ui = <div>Hello {subject}</div>
ui = React.createElement('div', null, 'Hello ', subject)

ui = (
  <div>
    {gretting} {subject}
  </div>
)
ui = React.createElement('div', null, gretting, ' ', subject)

ui = <button onClick={() => {}}>click me</button>
ui = React.createElement('button', {onClick: () => {}}, 'click me')

ui = <div>{error ? <span>{error}</span> : <span>good to go</span>}</div>
ui = React.createElement(
  'div',
  null,
  error 
    ? React.createElement('span', null, error)
    : React.createElement('span', null, 'good to go'),
)

ui = (
 <div>
   {itmes.map(i => (
     <span key={i.id}>{i.content}<span>
   )}
 </div>
)
ui = React.createElement(
  'div',
  null,
  items.map(i => React.createElement('span', {key: i.id}, i.content)),
)

 

`{`와 `}`의 사이에 넣는 것은 그대로 남겨진다는 것을 눈치챌 수 있습니다. 이를 interpolation 이라 부르고  props의 값과 자식들에 변수들을 동적으로 주입할 수 있습니다. 이러한 방식으로 동작을 하기 때문에 interpolation에 넣는 컨텐츠들은 무조건 Javascript 표현식 이여야 합니다. 그것들은 객체 할당의 우측 혹은 함수 호출의 인자에 본질적으로 사용되기 때문입니다.

 

 

Conclusion

좀 더 많은것을 다루어 보고 싶다면 Babel의 온라인 REPL(Read, Eval, Print, Loop)을 시도할 수 있습니다. JSX가 어떻게 동작하는 지 좀 더 이해할 수 있고 좀 더 효율적으로 사용할 수 있도록 도와줍니다. Good luck!

 

 

 


출처 : https://kentcdodds.com/blog/what-is-jsx

 

What is JSX?

You may use it every day, but have you seen what happens after Babel compiles it?

kentcdodds.com

 

728x90
반응형

이 글은 아래 출처의 글을 번역한 글입니다. 오역과 의역을 자주 사용합니다.

 

 

리액트 리렌더와 관련된 블로그 포스트를 준비하고 있었는데 우연히 작은 React 지식을 발견했고 여러분께 도움이 되리라 생각합니다.

 

 

이 블로그 포스트를 읽은 후에 Brooks Lybrand는 이 트릭을 구현했고 아래는 그 결과 입니다.

 

흥미롭나요? 단순한 예제와 함께 살펴보고 여러분의 앱을 위한 실용적인 예제에 대하여 이야기 해봅시다

 

An example

// play with this on codesandbox: https://codesandbox.io/s/react-codesandbox-g9mt5

import * as React from 'react'
import ReactDOM from 'react-dom'

function Logger(props) {
  console.log(`${props.label} rendered`)
  return null
}

function Counter() {
  const [count, setCount] = React.useState(0)
  const increment = () => setCount(c => c + 1)
  return (
    <div>
      <button onClick={increment}>The count is {count}</button>
      <Logger label="counter" />
    </div>
  )
}

ReactDOM.render(<Counter />, document.getElementById('root'))

 

이것이 동작할때 "counter rendered"는 콘솔에 즉시 찍힙니다. 그리고 count가 증가될때마다 "counter rendered"는 콘솔에 출력될 겁니다. 버튼이 클릭되었고 상태가 변했기 때문에 발생합니다. React는 상태 변화에 근하여 새로운 React 요소를 가져와서 렌더 해야 하기 위해 알아야 합니다. 새로운 요소를 가져올때 렌더되고 DOM에 커밋 됩니다.

 

여기에 흥미로운 요소가 있습니다. `<Logger label="counter"/>`는 사실 렌더간에 절대 변하지 않습니다. 이것은 정적입니다 그러므로 추출될 수 있습니다.재미로 한번 시도해봅시다. (이걸 추천하지는 않습니다. 이따 실용적인 추천이 나올때까지 좀만 기다려주세요)

 

// play with this on codesandbox: https://codesandbox.io/s/react-codesandbox-o9e9f

import * as React from 'react'
import ReactDOM from 'react-dom'

function Logger(props) {
  console.log(`${props.label} rendered`)
  return null // what is returned here is irrelevant...
}

function Counter(props) {
  const [count, setCount] = React.useState(0)
  const increment = () => setCount(c => c + 1)
  return (
    <div>
      <button onClick={increment}>The count is {count}</button>
      {props.logger}
    </div>
  )
}

ReactDOM.render(
  <Counter logger={<Logger label="counter" />} />,
  document.getElementById('root'),
)

 

변화를 눈치챘나요? 네 우리는 시작 로그를 가지게 됩니다. 그러나 버튼을 클릭했을때 새로운 로그는 얻지 못합니다

 

 

What's going on?

 

무엇이 이 차이를 유발했을까요? 리액트 요소와 관련이 있습니다. React 요소와 그들과 JSX의 관계를 빠르게 refresh 하기위해 "What is JSX?" 이 글을 잠시 멈추고 읽고 오는건 어떨까요? 

 

리액트가 counter 함수를 호출할 때, 아래와 같이 보이는 것을 가져옵니다.

 

const counterElement = {
  type: 'div'
  props: {
    children: [
      {
        type: 'button',
        props: {
          onClick: increment, // this is the click handler function
          children: 'The count is 0'
        },
      }, {
        type: Logger,
        props: {
          label: 'counter',
        }
      }
    ]
  }
}

 

이들은 UI 묘사 객체로 불립니다. 그들은 React가 DOM 에서 생성해야 하는 UI를 묘사합니다. 버튼을 누르고 변화를 살펴봅시다

const counterElement = {
  type: 'div',
  props: {
    children: [
      {
        type: 'button',
        props: {
          onClick: increment,
          children: 'The count is 1',
        ]
      }, 
      {
        type: Logger,
        props: {
          label: 'counter'
        }
      }
    ]
  }
}

 

우리가 호출을 아무리 많이 해도 button의 `onClick`과 `children` prop만 변화합니다. 그러나 이 모든 것은 완전히 새롭습니다. React가 사용되던 초기 이후에 여러분은 이러한 객체를 매 렌더마다 새로 생성하였었습니다. (운이 좋게도, 모바일 브라우저에서도 이 동작은 빠릅니다. 그래서 특별한 성능 문제는 발생하지 않았습니다.)

 

React 요소가 렌더간에 같은지 tree 일부분에서 검사하는 것이 훨씬 쉬울것입니다. 아래에는 렌더간에 변화하지 않는 것들이 있습니다.

const counterElement = {
  type: 'div',  // 변화 🔴
  props: {
    children: [
      {
        type: 'button',  // 변화 🔴
        props: {
          onClick: increment,
          children: 'The count is 1',
        },
      },
      {
        type: Logger,  // 변화 🔴
        props: {
          label: 'counter',  // 변화 🔴
        },
      },
    ],
  },
}

 

모든 요소의 type은 동일하고 Loger 요소의 `label` prop도 변화하지 않습니다. 그러나 props 객체는 렌더 간에 스스로 변화합니다. 이전 prop 객체와 객체의 property들이 같을지라도 말이빈다.

 

자 여기에 kicker가 있습니다. Logger props 객체가 변화되었기 때문에 React는 새로운 prop객체에 기반하여 새로운 JSX를 가져와야 하는지 확인하기 위해  Logger 함수를 재동작해야할 필요가 있습니다.  그런데 render간에 prop의 변화를 막을 수 있다면 어떨까요??

만약 prop이 바뀌지 않았다면 React는 JSX는 바뀌지 않을거고 함수의 재동작도 필요없다고 알수 있습니다. 이건 React에 다음과 같이 작성이 되어있고 React가 처음 시작할 때부터 그랬습니다.

 

그러나 문제는 우리가 새로운 React 요소를 생성할 때 마다 react는 새로운 `props` 객체를 만드는 것입니다. 그러면 어떻게 우리가 렌더 간에 props 객체가 변화하지 않았다라는 것을 보장할 수 있을까요?

이제 두번째 예제에서 Logger가 리렌더 되지 않는 것을 이해하고 가닥이 잡혔길 바랍니다.

 

Let's bring it back together

 

두번째 예제를 다시 보겠습니다.

// play with this on codesandbox: https://codesandbox.io/s/react-codesandbox-o9e9f

import * as React from 'react'
import ReactDOM from 'react-dom'

function Logger(props) {
  console.log(`${props.label} rendered`)
  return null // what is returned here is irrelevant...
}

function Counter(props) {
  const [count, setCount] = React.useState(0)
  const increment = () => setCount(c => c + 1)
  return (
    <div>
      <button onClick={increment}>The count is {count}</button>
      {props.logger}
    </div>
  )
}

ReactDOM.render(
  <Counter logger={<Logger label="counter" />} />,
  document.getElementById('root'),
)

 

렌더 간에 같은 것들을 찾아보겠습니다.

 

Logger 요소는 완벽히 변하지 않기 때문에 React는 자동적으로 최적화를 제공할 수 있고 Logger 요소가 리렌더 되지 않아도 된다는 것을 알 수 있습니다. prop들을 개별적으로 검사하는 것을 제외하고 `React.memo`와 기본적으로 유사합니다. React는 prop 객체를 전체적으로 확인합니다.

 

So what does this mean for me?

요약하자면 성능이슈를 경험하셨다면 아래와 같이 시도해보세요

 

  1. 비용이 비싼 컴포넌트를 부모로 올려서 render가 적게 되게 해보세요
  2. 비용이 비싼 컴포넌트를 prop으로 전달합니다

 

코드에 거대한 데이밴드를 분이는 것과 같이  `React.memo`의 빈번한 쓰임 없이 퍼포먼스 문제를 해결할 수 있습니다.

 

Demo

 

React에서 느린 앱의 실제 데모를 만드는 것은 전체 앱을 구축해야 하기 때문에 까다로워서 저는 before/after를 확인해볼 수 있는 예시를 만들었습니다.

 

 

 

 

 첨언하고 싶은 것은 코드의 빠른 버전을 사용하는 것이 더 나을지라도 , 초기 렌더링 시에는 성능이 여전히 떨어집니다. 그리고 만약 다른 top-down 리렌더가 필요하다면 성능은 좋지 않을것입니다. 그것은 아마도 자체적인 장점에 따라 다루어져야 하는 성능 문제입니다. 또한 codesandbox는 React development 버전을 사용했다는 것을 기억해주세요 좋은 개발경험을 주지만 production 버전보다는 성능이 느립니다.

 

그리고 이는 앱의 상위 단계에서만 유용한 것이 아닙니다. 앱에서 필요한 어느곳에서라도 적용할 수 있습니다.  제가 이것에 관하여 좋아하는 것은 "구성에 있어 자연스럽고 최적화의 기회로 작용합니다." 그래서 거부감이 없었고 퍼포먼스 성능도 공짜로 얻었습니다. 그리고 이것이 React와 관련하여 제가 좋아하는 것입니다. React는 React앱이 기본적으로 빠르도록 작성되었고 React는 함정을 피할 수 있게 최적화 helper를 제공합니다.

 

 


 

출처 : https://kentcdodds.com/blog/optimize-react-re-renders

 

One simple trick to optimize React re-renders

Without using React.memo, PureComponent, or shouldComponentUpdate

kentcdodds.com

 

728x90
반응형

얼마전, React 컴포넌트를 향상시키기 위한 state reducer pattern이라고 불리는 새로운 패턴을 개발했습니다. 이것을 downshift 내부 상태를 업데이트 하고 싶어하는 사람들에게 훌륭한 API 사용을 가능하게 하기 위해 downshift에서 사용하였습니다.

 

만약 downshift에 익숙하지 않다면, 접근 가능한 autocomplete/typeahead/dropdown 컴포넌트들과 같은 것을 만들 수 있는 '향상된 input' 컴포넌트 라는 것만 알면 됩니다. `isOpen`, `selectedItem`, `highlightedIndex`와 `inputValue와 같은 상태를 관리한다는 것을 아는것은 중요합니다.

Downshift는 현재 prop component를 render하도록 구현되어 있습니다. 그 당시에 prop을 렌더하는 것은 UI의 고정 없이 로직을 공유할수 있게 해주는 "Headless UI Component" 를 만들기 위한 최고의 방법이었습니다.  이것이 downshift가 성공적이었던 주요 이유중 하나입니다.

 

오늘날에는 React hook이 있고 hook은 rener props 보다 더 잘 수행할 수 있는 방법입니다. 그래서 이 패턴이 React 팀이 제공한 새로운 API를 이용해 어떻게 업데이트 될 수 있는지 보여줘야 겠다고 생각했습니다. (Note: Downshift has plans to implement a hook)

 

다시 상기시키는 개념으로 state reducer 패턴의 이점은 사실 "inversion of control" 을 허용한다는 것에 있습니다. "inversion of control"은 API를 사용하는 이에게 내부적으로 어떻게 동작할지에 대한 권한을 부여하는 기본적인 메커니즘 입니다. 이에 대한 예시를 들어보자면 아래의 React Rally 2018을 보는것을 강력하게 권장합니다.

 

https://www.youtube.com/watch?list=PLV5CVI1eNcJgNqzNwcs4UKrlJdhfDjshf&v=AiJ8tRRH0f8&feature=youtu.be 

 

Read also on my blog: "Inversion of Control"

 

downshift 예제에서 유저가 아이템을 선택했을때 isOpen 상태가 false로 설정될 수 있도록 결정을 내렸습니다.(메뉴는 닫힐수 있습니다.)

누군가는 downshift와 함께 복수 선택을 만들고 있었고 유저가 메뉴의 아이템을 선택한 이후에도 열려있기를 원했습니다.(그래야지 그들이 더 많은 것을 선택할 수 있으니까요)

 

state reducer 패턴을 이용한 상태 업데이트에 대한 제어의 역전으로 그들의 경우와 downshift 내부적인 동작들을 변경하고 싶어하는 가능성이 있을 수 있는 사람들의 경우에도 가능하게 할 수 있었습니다. 제어의 역전은 컴퓨터 공학 원칙을 가능하게 해주었고 state reducer 패턴은 일반 컴포넌트에서 동작되었던 것보다 훅으로 더 잘 변환되는 놀라운 구현입니다. 

 

Using a State Reducer with Hooks

자, 개념은 아래와 같이 동작합니다 : 

  1. 사용자가 작업을 수행합니다.
  2. dispatch를 호출합니다.
  3. 훅은 변화가 필요한지 결정합니다.
  4. 훅이 이후의 변화를 위한 코드를 호출합니다.  👈 제어의 역전이 이뤄지는 부분입니다.
  5. 훅은 상태를 변화시킵니다.

WARNING: Contrived example ahead: 단순함을 유지하기 위해 단순한 `useToggle` 훅과 간단한 컴포넌틑를 사용할 겁니다. 조작되었다고 느낄수 있지만 이 패턴을 훅으로 동작시키는 것을 알려주는데 있어 복잡한 예시로 혼란을 주고 싶지 않습니다. 복잡한 훅과 컴포넌트에 적용했을때 이 패턴이 잘 동작한다는 것을 아는게 중요합니다.

 

function useToggle() {
  const [on, setOnState] = React.useState(false)
  
  const toggle  = () => setOnState(o => !o)
  const setOn = () => setOnState(true)
  const setOff = () => setOnState(false)
  
  return { on, toggle, setOn, setOff }
}

function Toggle() {
  const {on, toggle, setOn, setOff} = useToggle()
  
  return (
    <div>
      <button onClick={setOff}>Switch Off</button>
      <button onClick={setOn}>Switch On</button>
      <Switch on={on} onClick={toggle} />
    </div>
  )
}

function App() {
  return <Toggle />
}

ReactDOM.render(<App />, document.getElementById('root'))

 

이제 사용자가 "Reset" 버튼을 클릭하지 않으면 사용자는 `<Switch />`를 4번 이상 클릭할 수 없도록 `<Toggle />` 컴포넌트를 변경해야 한다고 가정하겠습니다.

 

function Toggle() {
  const [clicksSinceReset, setClicksSinceReset] = React.useState(0)
  const tooManyClicks = clicksSinceReset >= 4
  
  const {on, toggle, setOn, setOff} = useToggle()
  
  function handleClick() {
    toggle()
    setClicksSinceReset(count => count + 1)
  }
  
  return (
    <div>
      <button onClick={setOff}>Switch Off</button>
      <button onClick={setOn}>Switch On</button>
      <Switch on={on} onClick={handleClick}/>
      {
        tooManyClicks ? (
          <button onClick={() => setClicksSinceReset(0)}>Reset</button>
        ) : null
      }
    </div>
  )
}

 

좋습니다. 이 문제의 간단한 해결책은 `handleClick` 함수에 if문을 추가하고 `tooManyClicks`가 true일때 `toggle`을 호출하지 않는 것이 될 수 있습니다. 하지만 이 예제의 목적을 위해 keep going 하겠습니다.

 

이 상황에 제어의 역전을 위해 `useToggle` 훅을 어떻게 변경할 수 있을까요? API에 대해 먼저 생각해 보겠습니다. 그 다음이 구현입니다. 사용자 입장에서 실제로 발생하고 수정하기 전에 모든 상태 업데이트에서 훅이 동작할 수 있다면 좋을 것입니다.

 

function Toggle() {
  const [clicksSinceReset, setClicksSinceReset] = React.useState(0)
  const tooManyClicks = clicksSinceReset >= 4
  
  const {on, toggle, setOn, setOff} = useToggle({
    modifyStateChange(currentState, changes) {
      if (tooManyClicks) {
        // other changes are fine, but on needs to be unchanged
      	return {...changes, on: currentState.on}
      } else {
        // the changes are fine
        return changes
      }
    }
  })
  
  function handleClick() {
    toggle()
    setClicksSinceReset(count => count + 1)
  }
  
  return (
    <div>
      <button onClick={setOff}>Switch Off</button>
      <button onClick={setOn}>Switch On</button>
      <Switch on={on} onClick={handleClick}/>
      {
        tooManyClicks ? (
          <button onClick={() => setClicksSinceReset(0)}>Reset</button>
        ) : null
      }
    </div>
  )
}

 

`<Switch />`가 상태를 변화 시키는 것을 예방하기만을 원하고  "Switch Off" 혹은 "Switch On" 버튼을 클릭했을때를 눌렀을때의 동작을 막는것을 제외하고 괜찮아 보입니다. 

 

음.... `modifyStateChange`를 `reducer`를 이용해 변화시키고 두번째 인자로 `action`을 받으면 어떨까요? `action`은 어떠한 변화가 일어나야 하는지 결정할 수 있는 `type`을 가질수 있고 `useToggle` 훅으로부터 export 될수 있는 `toggleReducer`로 부터 `changes`를 가질 수 있습니다. 스위치를 클릭하는 `type`은 `TOGGLE` 이라 하겠습니다.

 

function Toggle() {
  const [clicksSinceReset, setClicksSinceReset] = React.useState(0)
  const tooManyClicks = clicksSinceReset >= 4
  
  const {on, toggle, setOn, setOff} = useToggle({
    reducer(currentState, action) {
      const changes = toggleReducer(currentState, action)
      if (tooManyClicks && action.type === 'TOGGLE') {
        // other changes are fine, but on needs to be unchanged
      	return {...changes, on: currentState.on}
      } else {
        // the changes are fine
        return changes
      }
    }
  })
  
  function handleClick() {
    toggle()
    setClicksSinceReset(count => count + 1)
  }
  
  return (
    <div>
      <button onClick={setOff}>Switch Off</button>
      <button onClick={setOn}>Switch On</button>
      <Switch on={on} onClick={handleClick}/>
      {
        tooManyClicks ? (
          <button onClick={() => setClicksSinceReset(0)}>Reset</button>
        ) : null
      }
    </div>
  )
}

 

좋습니다! 이것은 우리에게 모든 종류의 제어를 제공해 줍니다. 마지막 한가지는 `TOGGLE` 문자열을 사용하지 않는 것입니다. 대신 사용자가 대신 참조할 수 있는 모든 change type들을 가진 객체를 사용하겠습니다. 이것은 오타를 줄여주고 editor 자동완성을 향상시켜줍니다.

 

function Toggle() {
  const [clicksSinceReset, setClicksSinceReset] = React.useState(0)
  const tooManyClicks = clicksSinceReset >= 4
  
  const {on, toggle, setOn, setOff} = useToggle({
    reducer(currentState, action) {
      const changes = toggleReducer(currentState, action)
      if (tooManyClicks && action.type === actionTypes.toggle) {
        // other changes are fine, but on needs to be unchanged
      	return {...changes, on: currentState.on}
      } else {
        // the changes are fine
        return changes
      }
    }
  })
  
  function handleClick() {
    toggle()
    setClicksSinceReset(count => count + 1)
  }
  
  return (
    <div>
      <button onClick={setOff}>Switch Off</button>
      <button onClick={setOn}>Switch On</button>
      <Switch on={on} onClick={handleClick}/>
      {
        tooManyClicks ? (
          <button onClick={() => setClicksSinceReset(0)}>Reset</button>
        ) : null
      }
    </div>
  )
}

 

Implementing a State Reducer with Hooks

 

좋습니다. 여기에서 노출되고 있는 API에 저는 만족합니다. `useToggle` 훅을 어떻게 구현할 수 있는지 살펴보겠습니다. 잊어버렸을 경우를 대비하여 아래에 준비하였습니다 : 

 

function useToggle() {
  const [on, setOnState] = React.useState(false)

  const toggle = () => setOnState(o => !o)
  const setOn = () => setOnState(true)
  const setOff = () => setOnState(false)

  return {on, toggle, setOn, setOff}
}

 

이러한 helper 함수에 모두가 로직을 추가할 수 있지만 이 과정은 넘어가고 이것은 단순한 훅일지라도 번거라운 일이라고 언급하려 합니다. 대신에 이 형태를 `useStatea`에서 `useReducer`로 재작성하고 구현을 훠얼씬 쉽게 만들어보겠습니다.

 

function toggleReducer(state, action) {
  switch (action.type) {
    case 'TOGGLE': {
      return {on: !state.on}
    }
    case 'ON': {
      return { on: true }
    }
    case 'OFF': {
      return { on: false }
    }
    default: {
      throw new Error(`Unhandled type: ${action.type}`)
    }
  }
}

function useToggle() {
  const [{on}, dispatch] = React.useReducer(toggleReducer, {on: false})
  
  const toggle = () => dispatch({type: 'TOGGLE'})
  const setOn = () => dispatch({type: 'ON'})
  const setOff = () => dispatch({type: 'OFF'})
  
  return {on, toggle, setOn, setOff}
}

 

좋습니다. 매우 빠르네요. 문자열로 전달되는 것을 피하기 위해 `useToggle`에 `types` 속성을 추가하겠습니다. 그리고 훅에서 export 하여 사용자들이 참조할 수 있도록 할겁니다.

 

const actionTypes = {
  toggle: 'TOGGLE',
  on: 'ON',
  off: 'OFF',
}

function toggleReducer(state, action) {
  switch (action.type) {
    case actionTypes.toggle: {
      return {on: !state.on}
    }
    case actionTypes.on: {
      return { on: true }
    }
    case actionTypes.off: {
      return { on: false }
    }
    default: {
      throw new Error(`Unhandled type: ${action.type}`)
    }
  }
}

function useToggle() {
  const [{on}, dispatch] = React.useReducer(toggleReducer, {on: false})
  
  const toggle = () => dispatch({type: actionsTypes.toggle})
  const setOn = () => dispatch({type: actionsType.on})
  const setOff = () => dispatch({type: actionTypes.off})
  
  return {on, toggle, setOn, setOff}
}

export {useToggle, actionTypes}

 

좋습니다. 이제 사용자들은 `useToggle`함수에  configuration 객체로서 `reducer`를 전달할 것입니다. 이걸 적용해 보겠습니다.

 

function useToggle({reducer}) {
  const [{on}, dispatch] = React.useReducer(toggleReducer, {on: false})
  
  const toggle = () => dispatch({type: actionTypes.toggle})
  const setOn = () => dispatch({type: actionTypes.on})
  const setOff = () => dispatch({type: actionTypes.off})
  
  return {on, toggle, setOn, setOff}
}

 

좋습니다. 이제 개발자의 `reducer`가 생겼으니 우리의 reducer와 어떻게 결합할 수 있을까요? 사실 우리의 훅에대해 진정으로 제어의 역전을 바랐다면 우리는 우리의 `reducer`를 호출하지 않길 원한다. 대신에 우리의 reducer를 노출하고 그들 스스로 원하는대로 사용할 수 있게 하면 된다.  이걸 export 하자. 우리는 `reducer`를 사용할 거고 그들은 우리 대신에 제공할 겁니다.

 

function useToggle({reducer}) {
  const [{on}, dispatch] = React.useReducer(reducer, {on: false})
  
  const toggle = () => dispatch({type: actionTypes.toggle})
  const setOn = () => dispatch({type: actionTypes.on})
  const setOff = () => dispatch({type: actionTypes.off})

  return {on, toggle, setOn, setOff}
}

export {useToggle, actionTypes, toggleReducer}

 

좋습니다. 그러나 이제 우리 컴포넌트를 사용하는 모두가 reducer 제공을 원하지 않아도 제공해야 합니다. 제어의 역전을 원하는 사람을 위해 제어 역전이 가능하게 해주고 싶습니다. 그러나 일반적인 경우에는 특별한 작업을 수행할 필요가 없으므로 기본값을 추가하겠습니다 :

 

function useToggle({reducer = toggleReducer} = {}) {
  const [{on}, dispatch] = React.useReducer(reducer, {on: false})

  const toggle = () => dispatch({type: actionTypes.toggle})
  const setOn = () => dispatch({type: actionTypes.on})
  const setOff = () => dispatch({type: actionTypes.off})

  return {on, toggle, setOn, setOff}
}

export {useToggle, actionTypes, toggleReducer}

 

만족스럽네요, 이제 사용자들은 내장되어 있거나 자신의 reducer와 함께 `useToggle`훅을 사용할 수 있습니다. 둘다 잘 동작합니다.

Conclusion

여기 최종 버전이 있습니다.

 

import * as React from 'react'
import ReactDOM from 'react-dom'
import Switch from './switch'


const actionTypes = {
  toggle: 'TOGGLE',
  on: 'ON',
  off: 'OFF',
}

function toggleReducer(state, action) {
  switch (action.type) {
    case actionTypes.toggle: {
      return {on: !state.on}
    }
    case actionTypes.on: {
      return {on: true}
    }
    case actionTypes.off: {
      return {on: false}
    }
    default: {
      throw new Error(`Unhandled type: ${action.type}`)
    }
  }
}

function useToggle({reducer = toggleReducer} = {}) {
  const [{on}, dispatch] = React.useReducer(reducer, {on: false})

  const toggle = () => dispatch({type: actionTypes.toggle})
  const setOn = () => dispatch({type: actionTypes.on})
  const setOff = () => dispatch({type: actionTypes.off})

  return {on, toggle, setOn, setOff}
}

// export {useToggle, actionTypes, toggleReducer}

function Toggle() {
  const [clicksSinceReset, setClicksSinceReset] = React.useState(0)
  const tooManyClicks = clicksSinceReset >= 4

  const {on, toggle, setOn, setOff} = useToggle({
    reducer(currentState, action) {
      const changes = toggleReducer(currentState, action)
      if (tooManyClicks && action.type === actionTypes.toggle) {
        // other changes are fine, but on needs to be unchanged
        return {...changes, on: currentState.on}
      } else {
        // the changes are fine
        return changes
      }
    },
  })

  return (
    <div>
      <button onClick={setOff}>Switch Off</button>
      <button onClick={setOn}>Switch On</button>
      <Switch
        onClick={() => {
          toggle()
          setClicksSinceReset(count => count + 1)
        }}
        on={on}
      />
      {tooManyClicks ? (
        <button onClick={() => setClicksSinceReset(0)}>Reset</button>
      ) : null}
    </div>
  )
}

function App() {
  return <Toggle />
}

ReactDOM.render(<App />, document.getElementById('root'))

 

codesandbox에서의 동작을 확인할 수 있습니다.

 

 

기억해야 할, 우리가 여기서 한 것은 사용자가 모든 상태 업데이트를 우리의 reducer로 변화를 만들 수 있게 한것이다.  이건 우리의 hook을 좀 더 유연하게 할것입니다. 하지만 우리가 상태를 업데이트하는 방식이 이제 API의 일부라는 것을 의미하고 이 변화가 일어나는 것을 바꾸려 한다면 사용자들 에게는 큰 변화가 될것입니다. 복잡한 훅/컴포넌트들에는 가치있는 trade-off 이지만 이 점은 명심하는 것이 좋습니다.

 

여러분이 이 사용성과 같은 패턴을 발견하길 희망합니다. `useReducer` 덕분에, just kinda falls out. 여러분의 코드에 적용해 보세요

 

Good luck!!

 


 

 

출처 : https://kentcdodds.com/blog/the-state-reducer-pattern-with-react-hooks

 

The State Reducer Pattern with React Hooks

A pattern for you to use in custom hooks to enhance the power and flexibility of your hooks.

kentcdodds.com

 

728x90

+ Recent posts