공부정리

https://p-iknow.netlify.app/front-end/react-codespliting

https://medium.com/humanscape-tech/react%EC%97%90%EC%84%9C-%ED%95%B4%EB%B3%B4%EB%8A%94-%EC%BD%94%EB%93%9C-%EC%8A%A4%ED%94%8C%EB%A6%AC%ED%8C%85-code-splitting-56c9c7a1baa4

프로젝트들에 모노레포를 적용하면서 했던 의사결정과 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을 심링크로 연결한다

(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), 라이브러리의 선택 기준등 

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

개념

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__ }),
};

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으로서의 단순한 컴포넌트들

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

우리가 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하지 않아야 합니다. 이것이 컨테이너의 역할 입니다.

Organimsms, Everywhere

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

이커머스 웹사이트와 상품 페이지가 있다고 가정해볼게요. Navbar organism과 상품 molecule를 가지고 있는 ProductGrid 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를 만들수 있습니다.

그래서 어느 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

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

• 어떻게 하면 다양한 경우에 적합한 재사용 가능한 컴포넌트를 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

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장 이었습니다.