당신에게 Redux는 필요 없을지도 모릅니다.

이 글은 Dan Abramov의 You Might Not Need Redux를 번역한 글입니다.

사람들은 종종 Redux가 필요하기도 전에 이를 선택하고는 합니다. “우리 앱이 Redux도 없이 커지면 어쩌죠?” 그리고 나서는 Redux가 코드에 가져오는 빙 돌아가는 방식에 대해 불평합니다. “왜 간단한 기능 하나를 위해 파일 세 개를 수정해야 하죠?” 왜 그렇겠습니까!

사람들은 그들에게 고통을 주는 Redux, React, 함수형 프로그래밍, 불변성, 그 외에 여러 가지를 탓합니다. 이해합니다. 보일러 플레이트 없이도 상태를 변경하는 다른 접근법들과 Redux를 비교하고 Redux가 단지 너무 복잡하다고 결론짓는 건 자연스러운 일입니다. Redux는 그런 식으로 작동하고, 그런 식으로 디자인되었습니다.

Redux는 등가교환을 가져옵니다. 이렇게 제안하죠:

  • 앱의 상태를 평범한 객체와 배열로 만드세요.
  • 시스템 내의 변경사항을 평범한 객체로 만드세요.
  • 변경을 다루는 로직을 순수함수로 만드세요.

이러한 제약 중 어떤 것도 앱을 만드는 데 있어서 필수는 아닙니다. React를 쓰든 말든요. 사실 이것들은 꽤 강한 제약이고, 앱 일부에라도 적용하기 전에 신중하게 생각해봐야 합니다.

이렇게 해야 할 정말 좋은 이유가 있나요?

이들 제약은 다음과 같은 앱을 만드는 데 도움을 주기 때문에 저에게 매력적이었습니다:

당신이 확장 가능한 터미널이나, 자바스크립트 디버거나, 어떤 웹앱을 만들고 있다면 한번 Redux를 시도해보거나 이들 아이디어 중 몇 가지를 고려해볼 만할 겁니다.(그나저나, 이것들은 새로운 것도 아닙니다!)

하지만, 만약 당신이 React를 이제 막 배웠다면, Redux를 첫 선택으로 하지는 마세요.

그 대신 React로 생각하기를 배우세요. 만약 정말 필요하다면 Redux로 돌아올 수도 있고, 뭔가 새로운 걸 시도해볼 수도 있습니다. 하지만 매우 의견이 강한 도구를 사용한다고 여기고 조심스럽게 접근해야 합니다.

뭔가를 “Redux의 방식으로” 해야 한다고 느낀다면, 아마 당신이나 팀원들이 너무 진지하게 말하는 걸 수도 있습니다. 이건 그냥 당신 도구상자에 있는 도구 중 좀 시끌벅적했던 실험 하나일 뿐입니다.

마지막으로, Redux의 아이디어를 Redux 없이도 적용할 수 있다는 걸 잊지 마세요. 예를 들어, 지역 상태를 가진 React 컴포넌트 하나를 생각해봅시다:

이대로도 완벽히 괜찮습니다. 진지하게, 반복해서 말할 가치가 있습니다.

지역 상태는 괜찮습니다.

"무엇이 일어나는가"와 "어떻게 바꾸는가"를 분리하기 위해 빙 돌아가는 방식을 추가하는 것이 Redux가 제안하는 등가교환입니다.

이런 식으로 하는 게 항상 좋을까요? 아뇨. 등가교환입니다.

예를 들어, 위의 컴포넌트에서 리듀서를 분리해낼 수 있습니다.

DYI Redux

이렇게 해서 npm install을 실행하지 않고도 Redux를 사용했다는걸 눈치채셨을겁니다. 와우!

상태를 가진 컴포넌트들에 전부 이런 식으로 해야 할까요? 아마도 아닐겁니다. 이렇게 빙 돌아가는 방식을 통해 뭔가 이득을 얻으려는 계획이 없다면요. 계획을 세우는건 요즘 식으로 말하자면 🔑입니다.

Redux 라이브러리 자체는 리듀서를 하나의 전역 스토어 객체에 “장착하는” 도우미들 모음일 뿐입니다. Redux를 거의 쓰지 않거나, 많이 쓰거나, 여러분이 원하는 대로 하세요.

하지만 만약 무언가를 포기한다면, 무언가를 꼭 얻어가세요.