Redux에서 MobX로 전환

우리가 여기 온 이유는 무엇인가요?

조만간 이 기능을 MobX 상태와 마찬가지로 다른 앱에서도 마찬가지입니다. 그래서 간단히 살펴보기로 했습니다. 그다지 많지 않을 것입니다. 코드 이미 들어보셨을 겁니다. Redux. 시작하겠습니다.

Redux란 무엇인가요?

에 명시된 바와 같이 redux.js.org에 대해 "예측 가능한 컨테이너 상태"입니다. JS 앱." 2015년 댄 아브라모프와 앤드류 클락이 만들었습니다.
다음과 같이 설명할 수 있습니다. 3가지 원칙:

1. 단일 진실 지점 - 상태가 단일 스토어에 보관됩니다,
2. 상태는 읽기 전용이므로 상태를 직접 변경할 수 없으며, 변경하려면 액션을 발생시켜야 합니다,
3. 순수 함수는 정의상 주어진 매개변수에 대해 항상 동일한 결과를 반환하고 항상 실행될 수 있으며 부작용이 없는 함수로 변경됩니다.

MobX란 무엇인가요?

놀랄 일도 아닙니다, MobX 역시 상태 관리를 위한 라이브러리로, 함수형 반응형 프로그래밍(TFRP)을 투명하게 적용하여 간단하고 확장성이 뛰어납니다. 앞의 라이브러리와 마찬가지로 그 철학은 세 가지로 설명할 수 있습니다:
1. 간단함 - 보일러가 필요 없는 최소한의 코드이며 작동에 특별한 도구가 필요하지 않습니다,
2. 손쉬운 최적 렌더링 - 모든 계산이 잘 최적화되도록 하며 수동으로 최적화할 필요가 없습니다,
3. 아키텍처의 자유로움 - 구현에 구애받지 않고 UI 프레임워크 없이도 사용할 수 있습니다.

MobX와 Redux 비교

학습

React 는 초기 설정과 관련된 심각한 상용구로 유명합니다. 이를 무시할 수 없습니다. 특히 감속기와 액션이 많은 대규모 애플리케이션의 경우, 액션 유형을 문자열에 상수로 유지하기로 이미 결정했을 것입니다. 이는 좋은 접근 방식이지만 코드가 훨씬 더 많아집니다! 다행히도 Redux 툴킷 가 더 많은 인기를 얻고 있으며 이제 다음을 작성하는 것이 좋습니다. Redux 로직. 제게 물어보면 마음에 듭니다! 아직 배울 것이 많지만 툴킷을 사용한 간단한 기본 설정만으로도 충분합니다.

제가 살펴본 결과 MobX 문서저는 마치 우연히 초콜릿 공장에 떨어진 어린아이가 된 것 같았습니다. 예제를 살펴보면서 어떻게 저렇게 작동할 수 있는지 계속 의문이 들었는데, 실제로 잘 작동하는 것 같았어요. 하지만 감속기, 액션, 미들웨어 등을 모두 다루다 보면 다른 것에 매료되기 쉬울 수도 있습니다. 그럼에도 불구하고 OOP에 익숙하다면, MobX 가 자연스럽게 떠오를 것입니다. 초기 코딩이 훨씬 적고 뒤에서 많은 일이 일어나기 때문에 대부분의 경우 신경 쓸 필요가 없습니다.

데이터 구조 - 상태 내부에는 무엇이 있나요?

In Redux를 사용하려면 프리미티브, 배열 또는 일반 JS 객체를 상태의 데이터로 사용합니다.
또한 데이터를 배열에 저장할 때 성능상의 이유로 데이터를 정규화하는 것이 일반적인 관행입니다. 안타깝게도 Redux 툴킷의 도우미 함수(예, 엔티티 어댑터 생성)를 사용하면 여전히 추가 코드가 추가됩니다.

In MobX속성, 전체 개체, 배열, 맵 및 집합을 만듭니다. 관찰 가능. 예, 프리미티브는 여기서는 언급되지 않았습니다. JS 는 변경할 수 없으므로 다르게 취급해야 합니다. 여러분이 알아야 할 모든 것 관찰 가능 는 프리미티브를 "상자"로 감싸고 실제 값 가져 오기 및 설정자는 다음을 통해 사용할 수 있습니다. .get() 그리고 .set(newValue) 각각 관찰 가능한 상자(값) 참조

"mobx"에서 { 관찰 가능, 자동 실행 } 가져오기

const cityName = observable.box("비엔나") // 관찰 가능("비엔나")과 동일합니다.

autorun(() => {
    console.log(cityName.get())
})
// 출력합니다: 'Vienna'

cityName.set("Amsterdam")
// 인쇄합니다: '암스테르담'

다음과 같이 데이터를 정규화할 필요가 없습니다. MobX 관찰 가능'는 객체를 복제하고 관찰 가능하게 만들어 관찰 가능한 속성을 업데이트하면 모든 변경 사항이 스토어에 반영되도록 합니다.

데이터 위치 - 스토어

신뢰할 수 있는 단일 소스 Redux. 상태를 한 곳에 유지함으로써 앱 전체에 데이터가 중복되지 않도록 하고 디버깅이 더 쉬워집니다.

MobX 는 실제로 UI 상태와 도메인 상태를 위해 하나 이상의 별도 저장소를 두는 것을 권장합니다. 이렇게 분리하면 다른 애플리케이션에서 도메인을 재사용할 수 있습니다.

다음과 같은 이유로 JS 일반 객체를 사용하는 경우, 저자가 제안한 것처럼 특정 도메인 객체에 대한 자체 클래스를 만드는 것이 자연스러워 보입니다. 여기, Mobx 는 객체 지향 프로그래밍을 좋아하는 분들에게 빛을 발합니다. 메서드를 가질 수 있고, 관찰 가능한 항목과 그렇지 않은 항목을 제어할 수 있습니다. 또한 여러 저장소를 결합하고 참조를 공유할 수 있습니다.

불변 및 변경 가능

Redux 상태 업데이트가 필요합니다. 돌연변이가 발생하지 않습니다. 를 원래 상태로 반환합니다. 따라서 기존 배열에 새 항목을 추가하려면 현재 배열에 해당 항목을 추가하는 대신 새 인스턴스를 반환해야 합니다.

함수 todoReducer(state = [], action) {
    // 여기서는 새 배열을 만들고 스프레드 연산자를 사용하여 이전 값을 유지합니다.
    반환 [
      ...state,
     action.payload
    ]
}

그런 다음 MobX에서 관찰 가능한 속성을 변경할 수 있습니다. 토도스 배열로 변경합니다. 원래 배열을 토도 추가

관찰 가능한 할일 저장소 클래스 {
  할일 = [];

  constructor() {
    makeObservable(this, {
      할일: 관찰 가능,
      addTodo: action,
    });
    autorun(() => console.log(this.todos.length))
  }


  addTodo(task) {
    //여기서는 새 항목을 기존 배열에 푸시하는 것입니다!
    this.todos.push({
      task: task,
      completed: false,
    });
  }

}

const observableTodoStore = new ObservableTodoStore();
관찰가능한 할일 저장소.추가할일("해야 할 힘든 일");

또한 직접 업데이트할 수도 있습니다. 할 일 목록에서 자동 실행 가 호출됩니다 ( 관찰 가능한 배열의 토도스).

관찰 가능한 할일 저장소.todos.push("다른 어려운 작업");

// 더 흥미로운 점은, 특정 할 일 속성을 업데이트할 때만
// 특정 할 일 속성을 업데이트할 때만 (엄격 모드에서) MobX가 직접 해서는 안 된다고 경고합니다.
관찰 가능한 할 일 저장소.todos[1].task = ("아마도 더 쉬운 작업");

디버깅

개인적으로 저는 Chrome Redux 개발자 도구 확장. 앱의 상태를 빠르게 살펴볼 수 있고 상태를 변경할 때마다 앞뒤로 이동할 수 있는 멋진 기능(시간 여행!)이 있습니다. 이 모든 것이 가능한 이유는 이전 상태를 변경하지 않는다는 원칙이 있기 때문입니다.

스토어에 추상화 계층이 추가되면 디버깅 프로세스가 더 어려워집니다. 스토어에서 MobX Chrome 확장 프로그램 는 이전과 비교하면 너무 번거로워 보이지만 익숙해지려면 시간이 좀 필요할 것 같습니다.

그러나 우리는 예를 들어 자동 실행 트랙 기능을 사용할 때 많이 사용하게 될 것입니다. MobX 를 사용하여 상태가 변경되는 시점을 확인하고자 합니다. 이 함수는 관찰한 변경 사항만 추적한다는 점에 유의해야 합니다. 이는 함수가 처음 실행될 때 결정됩니다. MobX 는 첫 번째 호출 중에 읽은 모든 관측값을 구독한 다음 변경될 때마다 트리거됩니다.

인기도

인기도를 보면 Redux가 우세합니다. Near 4백만 다운로드 주당 npm 대비 MobX의 경우 45만. 또한 각 라이브러리에 대한 GitHub 저장소의 기여자 수(~870명 > 270명)와 별 수(57천개 > 24천개)를 보면 Redux가 잘 알려진 브랜드라는 것을 알 수 있습니다.

반면에 JS 2020 현황 보고서 사용 만족도는 거의 동일한 수준으로 나타나므로 다음 제품을 선택하는 데 도움이 될 것입니다. 프로젝트.

이 차트의 만족도는 "다시 사용하겠다 / (다시 사용하겠다 + 다시 사용하지 않겠다)"로 설명되었습니다.

결론

이 콘테스트의 우승자는 아직 없습니다... 아직! BTW, 콘테스트는 전혀 없었습니다 😉 두 도서관 모두 기본 임무를 수행하는 데있어 훌륭한 일을하고 있다고 생각합니다. JS 애플리케이션 . 매일 어떻게 작동하는지 확인하려면 시간이 더 필요합니다. MobX 와 다릅니다. Redux 어떤 경우에 추천할 수 있는지 알아보세요.

현재로서는 Redux의 개발자 도구에서 "시간 여행"을 놓치고 있다고 말할 수 있지만, 다른 한편으로는 다음과 같은 상태를 설정합니다. MobX 는 매우 간단해 보이고 작성된 코드가 훨씬 더 읽기 쉬워 보입니다.

그럼에도 불구하고, 저는 어떻게 하면 관찰 가능 가 성능을 처리하는 마법을 볼 때마다 CPU 시간, 메모리, 드라이브 등 PC의 리소스가 얼마나 사용되고 있는지, 얼마나 효율적인지 궁금하기 때문입니다. 다음 단계의 연구 주제가 될 것입니다.

다음과 같은 특정 문제를 해결할 수 있는 방법에 대한 흥미로운 설명으로 다시 연락드리겠습니다. MobX. 그때 뵙겠습니다!