You Might Not Need Redux

https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367

You Might Not Need Redux

2016.09.20

 

사람들은 종종 Redux가 필요하기전에 선택합니다. 우리 앱이 리덕스 없이 확장할 수 있다면?

나중에, 개발자들은 필요없는 리덕스의 도입에 눈쌀을 찌푸립니다. 간단한 기능을 작동시키기 위해 내가 왜 세개의 파일을 만져야하는가?

 

사람들은 React, Redux, 함수형 프로그래밍, 불변성 및 기타 여러 가지 문제를 비난하며 저는 이러한 문제를 이해합니다. Redux로 상태를 업데이트하기 위해 보일러 플레이트 코드가 필요하지 않은 접근 방식과 비교하고 Redux가 단지 복잡하다고 결론을 내리는 것은 당연합니다. 

 

Redux는 트레이드 오프를 제공합니다. 

 

- 애플리케이션 상태를 일반 객체 및 배열로 설명합니다.

- 일반 객체로 애플리케이션의 변화를 설명합니다.

- 변경 사항을 순수함수로 처리하는 논리를 설명합니다.

 

React를 사용하거나 사용하지 않고 앱을 빌드하는데 이러한 제한이 필요하지 않습니다. 사실 이것은 매우 강력한 제약이며 앱의 일부에서라도 채택하기 전에 신중하게 생각해야합니다.

 

그렇게 해야할 타당한 이유가 있습니까?

이러한 제한 사항은 다음과 같은 앱을 빌드하는데 도움이 되기 때문에 매력적입니다.

 

- 로컬 스토리지에 상태를 유지한 다음 바로 불러와서 사용할 수 있습니다.

- 서버에서 상태를 미리 채우고 HTML로 클라이언트에 보내고 바로 부팅할 수 있습니다.

- 사용자 작업을 직렬화하고 이를 상태 스냅샷과 함께 자동화된 버그 보고서에 첨부하여 이를 재생하여 오류를 재현할 수 있도록 합니다.

- 코드 작성 방식을 크게 변경하지 않고 네트워크를 통해 작업 객체를 전달하는 환경 구현.

- 코드 작성 방식을 크게 변경하지 않고 실행 취소 기록을 유지하거나 optimistic mutation을 구현.

- 개발 중인 상태 기록 사이를 이동하고 TDD 처럼 코드가 변경되면 작업 기록에서 현재 상태를 재평가합니다.

- 제품 개발자가 앱을 위한 맞춤형 도구를 구축할 수 있도록 개발 도구에 전체 검사 및 제어 기능을 제공합니다.

- 대부분의 비즈니스 로직을 재사용하면서 대체 UI를 제공합니다.

 

만약 여러분이 확장 가능한 터미널, JavaScript 디버거 또는 다른 종류의 웹앱에서 작업하는 경우 시도해 보거나 최소한 몇가지 아이디어를 고려해 볼 가치가 있습니다. (그런데 새롭지는 않습니다.)

 

그러나 React를 배우는 중이라면 Redux를 첫 번째 선택으로 삼지 마십시오.

대신에 React로 생각하는 방법을 기르세요. 그 후에 Redux로 와서 실제로 필요하면 사용하세요. 또는 새로운 것을 시도하고 싶다면.

그러나 매우 독단적인 도구를 사용하는 것처럼 주의해서 접근하십시오.

 

여러분이 Redux 방식으로 작업해야 한다는 압박감을 느낀다면 여러분 또는 여러분의 팀원이 이를 너무 심각하게 받아들이고 있다는 신호일 수 있습니다. Redux는 당신의 도구상자에 있는 도구 중 하나일 뿐이며, 실험일 뿐입니다.

 

마지막으로 Redux를 사용하지 않고도 Redux의 아이디어를 적용할 수 있다는 점을 잊지 마십시오. 예를 들어 이 로컬 상태가 있는 React 컴포넌트를 고려하십시오.

 

import React, { Component } from 'react';

class Counter extends Component {
  state = { value: 0 };

  increment = () => {
    this.setState(prevState => ({
      value: prevState.value + 1
    }));
  };

  decrement = () => {
    this.setState(prevState => ({
      value: prevState.value - 1
    }));
  };
  
  render() {
    return (
      <div>
        {this.state.value}
        <button onClick={this.increment}>+</button>
        <button onClick={this.decrement}>-</button>
      </div>
    )
  }
}

 

 있는 그대로 완벽하게 괜찮습니다. 로컬 상태는 괜찮습니다. 

Redux가 제공하는 장단점은 "어떻게 변하는가"에서 "일어난 일"을 분리하기 위해 간접적인 정보를 추가하는 것입니다.(The tradeoff that redux offers is to add indirection to decouple "what happened" from "how things change".)

 

예를 들어 우리는 reducer를 컴포넌트로 부터 분리할 수 있습니다.

 

import React, { Component } from 'react';

const counter = (state = { value: 0 }, action) => {
  switch (action.type) {
    case 'INCREMENT':
      return { value: state.value + 1 };
    case 'DECREMENT':
      return { value: state.value - 1 };
    default:
      return state;
  }
}

class Counter extends Component {
  state = counter(undefined, {});
  
  dispatch(action) {
    this.setState(prevState => counter(prevState, action));
  }

  increment = () => {
    this.dispatch({ type: 'INCREMENT' });
  };

  decrement = () => {
    this.dispatch({ type: 'DECREMENT' });
  };
  
  render() {
    return (
      <div>
        {this.state.value}
        <button onClick={this.increment}>+</button>
        <button onClick={this.decrement}>-</button>
      </div>
    )
  }
}

 

npm install을 실행하지 않고 방금 Redux를 사용한 방법에 주목하십시오. 우와!

 

이렇게 컴포넌트를 구성할것입니까? 아마 여러분은 아니라고 대답할 것입니다. 왜냐면 이렇게 돌아가는 것으로 얻으 수 있는 이익을 따져봐야하기 때문입니다. 계획을 세우는 것은 우리시대의 용어로 🔑입니다.

 

Redux 라이브러리 자체는 리듀서를 단일 전역 저장소 객체에 "마운트" 하는 도우미 집합일 뿐입니다. 원하는 만큼 Redux를 적게 또는 많이 사용할 수 있습니다. 

 

그러나 당신이 무언가를 교환한다면, 당신이 그 대가로 무언가를 얻도록 확실히 하십시오.

 

⚛