Redux란 무엇인가: 디자이너 가이드

Redux라고 들어보셨나요? 그것은 무엇입니까? 구글링 금지, 제발!

• “멋진 백엔드 물건.”
• "라고 들어는 봤지만 뭔지 잘 모르겠습니다. React 프레임워크가 아닐까요?”
• "React 애플리케이션에서 상태를 저장하고 관리하는 더 나은 방법입니다."

40명이 넘는 디자이너에게 이 질문을 했습니다. 이상은 그들의 전형적인 답변입니다. 그들 중 많은 사람들이 Redux가 React와 함께 작동하고 그 역할이 "상태 관리"라는 것을 알고 있습니다.

그러나 이 "국가 관리"가 실제로 무엇을 의미하는지 아십니까? Redux의 진정한 힘은 상태를 관리하는 것 이상이라는 사실을 알고 계십니까? Redux가 작동하기 위해 반드시 React가 필요하지 않다는 것을 알고 계십니까? Redux를 사용할지 여부에 대한 팀 토론(또는 최소한 점심 채팅)에 참여하시겠습니까? Redux가 작동하는 방식을 염두에 두고 디자인하고 싶습니까?

이 기사의 도움으로 Redux가 무엇을 할 수 있는지, 왜 그 일을 하는지, 단점은 무엇인지, 언제 사용해야 하는지, 디자인과 어떤 관련이 있는지 등 Redux의 전체 그림을 보여주고 싶습니다 .

내 목표는 당신과 같은 디자이너를 돕는 것입니다. 이전에 한 줄의 코드를 작성하지 않았더라도 Redux를 이해하는 것이 여전히 가능하고 유익하고 재미있다고 생각합니다. 코드나 추상적인 대화 없이 평범한 영어와 기념일 로고를 기대하세요.

탈 준비가 되었나요?

Redux는 무엇입니까?

매우 높은 수준에서 Redux는 개발자가 삶을 더 쉽게 만드는 데 사용하는 도구입니다. 많은 분들이 들어보셨겠지만 그 역할은 "국가 관리"입니다. 상태 관리가 무엇을 의미하는지 나중에 몇 섹션에서 설명하겠습니다. 이 시점에서, 나는 당신에게 이 사진을 남길 것입니다:

왜 신경을 써야 합니까?

Redux는 모양과 느낌보다 앱의 내부 작동에 관한 것입니다. 가파른 학습 곡선이 있는 다소 복잡한 도구입니다. 그것은 디자이너로서 우리가 그것에서 멀리 떨어져 있어야 한다는 것을 의미합니까?

아니요. 저는 우리가 그것을 받아들여야 한다고 생각합니다. 자동차 디자이너는 엔진이 무엇을 위한 것인지 이해해야 합니다. 앱 인터페이스를 성공적으로 디자인하려면 디자이너는 내부에 대한 확실한 지식도 있어야 합니다 . 우리는 그것이 무엇을 할 수 있는지, 개발자들이 그것을 사용하는 이유를 이해하고, 장점과 의미를 알고 있어야 합니다.

“디자인은 단순히 보이는 것과 느끼는 것이 아닙니다. 디자인은 작동 방식입니다.”

— 스티브 잡스

Redux는 무엇을 할 수 있습니까?

많은 사람들이 Redux를 사용하여 React 앱에서 상태를 관리합니다. 이것은 야생에서 가장 일반적인 사용 사례이며 Redux는 React가 (아직) 잘 수행되지 않는 측면을 개선합니다.

그러나 곧 Redux의 진정한 힘이 그 이상이라는 것을 알게 될 것입니다. 상태 관리가 실제로 무엇을 의미하는지 배우면서 시작합시다.

상태 관리

이 "상태"가 무엇을 의미하는지 잘 모르겠다면 좀 더 일반적인 용어인 "데이터"로 바꾸겠습니다. 상태는 수시로 변경되는 데이터입니다 . 상태는 사용자 인터페이스에 표시되는 내용을 결정합니다.

국가 관리는 무엇을 의미합니까? 일반적으로 앱에서 관리해야 하는 데이터의 세 가지 측면이 있습니다.

1. 데이터 가져오기 및 저장
2. UI 요소에 데이터 할당
3. 데이터 변경

Dribbble 샷 페이지를 만들고 있다고 가정해 보겠습니다. 페이지에 표시하려는 데이터는 무엇입니까? 여기에는 작성자의 프로필 사진, 이름, 애니메이션 GIF, 하트 수, 댓글 등이 포함됩니다.

먼저 클라우드의 서버에서 이러한 모든 데이터를 가져와 어딘가에 저장해야 합니다. 다음으로 실제로 데이터를 표시해야 합니다. 이 데이터의 일부를 브라우저에서 실제로 보는 것을 나타내는 해당 UI 요소에 할당해야 합니다. 예를 들어 프로필 사진의 URL을 HTML img 태그의 src 속성에 할당합니다.

 <img src='https://url/to/profile_photo'>

마지막으로 데이터의 변경 사항을 처리해야 합니다. 예를 들어 사용자가 Dribbble 샷에 새 댓글을 추가하거나 별표를 추가하면 그에 따라 HTML을 업데이트해야 합니다.

상태의 이 세 가지 측면을 조정하는 것은 프론트 엔드 개발에서 큰 부분을 차지하며 React는 이 작업에 대해 다양한 수준의 지원 을 제공합니다. 때로는 React의 내장 기능이 충분히 잘 작동합니다. 그러나 앱이 더 복잡해짐에 따라 React 단독으로 상태를 관리하기가 더 어려워질 수 있습니다. 그렇기 때문에 많은 사람들이 Redux를 대안으로 사용하기 시작합니다.

데이터 가져오기 및 저장

React에서는 UI를 구성 요소로 나눕니다. 이러한 각 구성 요소는 더 작은 구성 요소로 나눌 수 있습니다("React이란?" 참조).

UI가 이런 방식으로 구성되어 있다면 UI를 채우기 전에 데이터를 언제 가져오고 어디에 저장할 것인가?

각 구성 요소에 요리사가 살고 있다고 상상해보십시오 . 서버에서 데이터를 가져오는 것은 요리를 준비하는 데 필요한 모든 재료를 소싱하는 것과 같습니다.

순진한 방법은 필요할 때 데이터를 가져와 저장하는 것입니다. 이것은 각 요리사가 멀리 떨어진 농장에서 직접 야채와 고기를 사러 나가는 것과 같습니다.

이 접근 방식은 낭비입니다. 동일한 데이터에 대해서도 많은 구성 요소에서 서버를 여러 번 호출해야 합니다. 요리사는 앞뒤로 이동하는 많은 가스와 시간을 낭비할 것입니다.

Redux를 사용하면 데이터를 한 번 가져와서 편리하게 "저장소"라고 하는 중앙 위치에 저장합니다. 그러면 데이터는 모든 구성 요소에서 언제든지 사용할 수 있습니다. 이것은 우리 요리사가 모든 재료를 구입할 수 있는 슈퍼마켓이 근처에 있는 것과 다르지 않습니다. 슈퍼마켓은 농장에서 대량으로 야채와 고기를 운반하기 위해 트럭을 보냅니다. 개별 요리사에게 농장에 직접 가도록 요청하는 것보다 훨씬 효율적입니다!

상점은 또한 진실의 단일 소스 역할을 합니다. 구성 요소는 항상 다른 곳이 아닌 저장소에서 데이터를 검색합니다. 이렇게 하면 모든 UI 콘텐츠가 일관되게 유지됩니다.

UI 요소에 데이터 할당

React만 있으면 실제로 데이터를 가져오고 저장하는 더 좋은 방법이 있습니다. 우리는 매우 친절한 요리사 Shotwell에게 그의 모든 요리사 친구들을 위해 쇼핑을 해달라고 요청할 수 있습니다. 그는 농장으로 트럭을 몰고 가서 음식을 다시 가져갈 것입니다. Dribbble 예제의 "Shot" 구성 요소와 같은 컨테이너 구성 요소에서 데이터를 가져와서 단일 소스로 사용할 수 있습니다.

이 접근 방식은 모든 구성 요소에서 데이터를 가져오는 순진한 방법보다 더 효율적입니다. 그러나 Shotwell은 다른 요리사에게 재료를 어떻게 전달합니까? HTML 요소를 실제로 렌더링하는 구성 요소에 데이터를 전달하는 방법은 무엇입니까? 우리는 데이터가 목적지에 도달할 때까지 외부 구성 요소에서 릴레이의 배턴과 같은 내부 구성 요소로 데이터를 전달합니다.

예를 들어 작성자 아바타의 URL은 "Shot"에서 "ShotDetail", "Title"로, 마지막으로 <img> 태그로 전달되어야 합니다. 우리 요리사가 아파트에 사는 경우 실제로는 다음과 같습니다.

데이터를 목적지로 전달하려면 데이터가 전혀 필요하지 않더라도 경로에 있는 모든 구성 요소를 연결해야 합니다. 층이 많으면 정말 짜증나겠죠!

대형마트가 방문 배달을 한다면? Redux ¹ 을 사용하면 다음과 같이 다른 구성 요소에 전혀 영향을 주지 않고 모든 데이터를 구성 요소에 연결할 수 있습니다.

¹ 절대적으로 정확하게 말하면 Redux 자체가 아니라 React 구성 요소에 데이터를 전달하는 react-redux 라는 또 다른 라이브러리입니다. 하지만 react-redux는 배관 작업만 하고 사람들은 거의 항상 Redux와 react-redux를 함께 사용하기 때문에 이것을 Redux의 장점 중 하나로 포함시키는 것이 좋다고 생각합니다.

참고 : 최신 버전의 React(16.3)에는 데이터를 구성 요소에 연결하는 측면에서 거의 동일한 작업을 수행하는 새로운 "컨텍스트" API가 있습니다. 따라서 이것이 팀에서 Redux를 사용하는 유일한 이유라면 React 16.3으로 업그레이드하는 것을 진지하게 고려하십시오! 자세한 내용은 공식 문서를 확인하세요(경고: 앞으로 많은 코드가 있음).

데이터 변경

때로는 앱에서 데이터를 업데이트하는 논리가 상당히 복잡할 수 있습니다. 여기에는 서로 의존하는 여러 단계가 포함될 수 있습니다. 애플리케이션 상태를 업데이트하기 전에 여러 서버의 응답을 기다려야 할 수도 있습니다. 다른 조건에서 다른 시간에 주의 많은 장소를 업데이트해야 할 수도 있습니다.

이 모든 논리에 대한 좋은 구조가 없으면 압도적일 수 있습니다. 코드를 이해하고 유지 관리하기 어려울 것입니다.

Redux를 사용하면 분할하고 정복할 수 있습니다. 데이터 업데이트 논리를 작은 "리듀서"로 나누는 표준 방법을 제공합니다. 이러한 감속기는 조화롭게 함께 작동하여 복잡한 작업을 완료합니다.

하지만 최근 React 개발을 주시하십시오. "컨텍스트" API와 마찬가지로 향후 버전의 React에는 새로운 "setState" API가 있을 수 있습니다. 복잡한 업데이트 논리를 더 작은 부분으로 나누기가 더 쉽습니다. 이 새로운 API를 사용할 수 있게 되면 상태 관리의 이러한 측면을 관리하기 위해 더 이상 Redux가 필요하지 않을 수 있습니다.

Redux의 진정한 힘

지금까지는 Redux가 React를 위한 반창고인 것 같습니다. 사람들은 React가 (아직) 잘 하지 못하는 측면을 개선하기 위해 Redux를 사용합니다. 그러나 React는 빠르게 따라잡고 있습니다! 사실 Redux의 창시자인 Dan Abramov는 몇 년 전에 Facebook의 React 핵심 팀에 합류했습니다. 그들은 앞서 언급한 React: 컨텍스트 API(16.3에서 출시), 더 나은 데이터 가져오기 API(2018년 2월에 데모), 더 나은 setState API 등의 개선 작업에 바빴습니다.

Redux를 쓸모없게 만들까요?

뭔지 맞춰봐? 나는 아직 Redux의 진정한 힘을 보여주지 않았습니다!

Redux는 개발자가 몇 가지 엄격한 규칙을 따르도록 하여 Redux에 많은 권한을 부여합니다(예, 규율의 힘!).

1. 모든 데이터(애플리케이션 상태)는 일반 텍스트로 설명되어야 합니다. 종이에 펜으로 모든 데이터를 쓸 수 있어야 합니다.
2. 모든 작업(데이터 변경)은 일반 텍스트로 설명되어야 합니다. 변경하기 전에 무엇을 할 것인지 기록해야 합니다. 흔적을 남기지 않고 데이터를 변경할 수 없습니다. 이 과정을 Redux 속어로 "dispatching action"이라고 합니다.
3. 데이터를 변경하는 코드는 수학 공식처럼 작동해야 합니다. 동일한 입력이 주어지면 동일한 결과를 반환해야 합니다. 4의 제곱은 아무리 많이 실행해도 항상 16입니다.

이러한 규칙을 따라 앱을 빌드하면 마법 같은 일이 일어납니다. 구현하기 어렵거나 비용이 많이 드는 멋진 기능을 많이 사용할 수 있습니다. 여기 예시들이 있습니다. ²

² 나는 Dan Abramov의 "You Might Not Need Redux" 포스트와 그의 "React Beginner Question Thread"에서 이러한 예를 수집했습니다.

실행 취소, 다시 실행

인기 있는 실행 취소/다시 실행 기능을 사용하려면 시스템 수준 계획이 필요합니다. 실행 취소/다시 실행은 앱의 모든 데이터 변경 사항을 기록하고 재생해야 하므로 처음부터 아키텍처에서 이를 고려해야 합니다. 나중에 생각하면 수많은 버그의 레시피인 많은 파일을 변경해야 합니다.

Redux는 모든 작업을 일반 텍스트로 설명해야 하기 때문에 실행 취소/다시 실행에 대한 지원은 거의 무료입니다. Redux로 실행 취소/다시 실행을 구현하는 방법에 대한 지침은 간단한 페이지에 적합합니다.

협업 환경

여러 사용자가 함께 복잡한 작업을 수행하는 Google 문서도구와 유사한 앱을 빌드하는 경우 Redux 사용을 고려하세요. 그것은 아마도 당신에게 많은 역도를 할 것입니다.

Redux를 사용하면 네트워크를 통해 일어나는 일을 매우 쉽게 보낼 수 있습니다. 다른 사용자가 다른 컴퓨터에서 수행하는 작업을 수신하고 변경 사항을 재생하고 로컬에서 일어나는 일과 병합하는 것은 간단합니다.

낙관적 UI

낙관적 UI는 앱의 사용자 경험을 개선하는 방법입니다. 앱이 느린 네트워크에서 더 빠르게 응답하는 것처럼 보이게 합니다. 1인칭 슈팅 게임과 같이 실시간 응답이 필요한 앱에서 널리 사용되는 전략입니다.

간단한 예를 들어, Twitter 앱에서 트윗의 하트를 클릭하면 해당 트윗이 아직 존재하는지 여부와 같은 몇 가지 검사를 수행하도록 서버에 요청해야 합니다. 결과를 몇 초 동안 기다리는 대신 앱은 속임수를 선택합니다! 모든 것이 괜찮다고 가정하고 즉시 채워진 마음을 보여줍니다.

이 접근 방식은 대부분의 경우 모든 것이 정상이므로 작동합니다. 상황이 좋지 않으면 앱은 이전 UI 업데이트를 되돌리고 서버의 실제 결과를 적용합니다(예: 오류 메시지 표시).

Redux는 실행 취소 및 다시 실행과 동일한 방식으로 낙관적 UI를 지원합니다. 서버에서 부정적인 결과를 수신할 때 데이터 변경 사항을 쉽게 기록, 재생 및 되돌릴 수 있습니다.

상태에서 지속 및 부팅

Redux를 사용하면 앱에서 일어나는 일을 저장소에 쉽게 저장할 수 있습니다. 나중에 컴퓨터가 다시 시작되더라도 앱은 중단된 적이 없는 것처럼 모든 데이터를 로드하고 정확히 같은 지점에서 계속할 수 있습니다.

Redux로 게임을 빌드하는 경우 나머지 코드를 변경하지 않고 게임 진행 상황을 저장/로드하기 위해 몇 줄의 코드만 더 있으면 됩니다.

정말 확장 가능한 시스템

Redux를 사용하면 앱의 모든 데이터를 업데이트하려면 작업을 "배포"해야 합니다. 이 제한으로 인해 앱에서 일어나는 일의 거의 모든 측면에 연결할 수 있습니다.

사용자가 모든 기능을 사용자 지정할 수 있는 확장 가능한 앱을 구축할 수 있습니다. 예를 들어 Redux로 빌드된 터미널 앱인 Hyper를 확인하십시오. "hyperpower" 확장은 커서에 스프링클을 추가하고 창을 흔듭니다. 이 "와우" 모드가 마음에 드시나요? (매우 유용하지는 않지만 사용자에게 깊은 인상을 주기에 충분함)

시간 여행 디버깅

앱을 디버깅할 때 시간 여행을 할 수 있다면 어떨까요? 버그가 발생한 정확한 위치를 찾기 위해 앱을 실행하고 몇 번 되감거나 앞으로 이동하고 버그를 수정하고 다시 재생하여 확인합니다.

Redux는 개발자의 이러한 꿈을 실현합니다. Redux DevTools를 사용하면 슬라이더를 드래그하여 실행 중인 앱의 진행 상황을 YouTube 동영상으로 조작할 수 있습니다!

어떻게 작동합니까? Redux가 시행하는 세 가지 엄격한 규칙을 기억하십니까? 그것이 마법의 비밀 소스입니다.

자동화된 버그 보고서

다음과 같이 상상해 보십시오. 사용자가 앱에서 잘못된 점을 발견하고 버그를 보고하려고 합니다. 그녀는 자신이 한 일을 열심히 회상하고 설명합니다. 그런 다음 개발자는 단계를 수동으로 수행하여 버그가 다시 발생하는지 확인합니다. 버그 보고서는 모호하거나 정확하지 않을 수 있습니다. 개발자는 버그가 있는 위치를 찾는 데 어려움을 겪고 있습니다.

이제 어때요? 사용자가 "버그 보고" 버튼을 클릭합니다. 시스템은 자동으로 그녀가 수행한 작업을 개발자에게 보냅니다. 개발자는 "버그 재생" 버튼을 클릭하고 해당 버그가 정확히 어떻게 발생하는지 관찰합니다. 벌레는 그 자리에서 박살내고 모두 대만족!

Redux Bug Reporter를 사용하면 정확히 이런 일이 발생합니다. 어떻게 작동합니까? Redux 제한 사항은 놀라운 일입니다.

Redux의 단점

Redux가 시행하는 세 가지 주요 규칙은 양날의 검입니다. 그들은 강력한 기능을 가능하게 하지만 동시에 피할 수 없는 단점을 야기합니다.

가파른 학습 곡선

Redux는 비교적 가파른 학습 곡선을 가지고 있습니다. 패턴을 이해하고 기억하고 익숙해지려면 시간이 걸립니다. Redux와 React가 모두 처음인 경우 동시에 배우는 것은 권장하지 않습니다.

"보일러 플레이트" 코드

많은 경우 Redux를 사용한다는 것은 더 많은 코드를 작성하는 것을 의미합니다. 간단한 기능이 작동하려면 여러 파일을 터치해야 하는 경우가 많습니다. 사람들은 Redux로 작성해야 하는 "보일러 플레이트" 코드에 대해 불평해 왔습니다.

나는 이것이 모순되게 들린다는 것을 압니다. Redux는 최소한의 코드로 기능을 구현할 수 있다고 말하지 않았습니까? 이것은 식기 세척기를 사용하는 것과 같습니다. 첫째, 접시를 일렬로 조심스럽게 배열하는 데 시간을 보내야 합니다. 그때까지는 식기 세척기의 이점을 알게 될 것입니다. 실제로 접시 세척, 접시 소독 등의 시간을 절약할 수 있습니다. 준비 시간이 그만한 가치가 있는지 결정해야 합니다!

성과 패널티

Redux는 또한 제한 사항으로 인해 성능에 영향을 줄 수 있습니다. 데이터가 변경될 때마다 약간의 오버헤드가 추가됩니다. 대부분의 경우 큰 문제가 아니며 속도 저하가 눈에 띄지 않습니다. 다만, 매장에 데이터가 많고 데이터가 자주 변경되는 경우(예: 모바일 장치에서 빠르게 입력하는 경우) 결과적으로 UI가 느려질 수 있습니다.

보너스: Redux는 React만을 위한 것이 아닙니다.

일반적인 오해는 Redux 가 React 전용이라는 것입니다. Redux는 React 없이는 아무것도 할 수 없는 것처럼 들립니다. 실제로 Redux는 앞에서 논의한 것처럼 몇 가지 중요한 방식으로 React를 보완합니다. 가장 일반적인 사용 사례입니다.

그러나 실제로 Redux는 Angular, Ember.js 또는 jQuery와 같은 모든 프론트 엔드 프레임워크 또는 바닐라 JavaScript와 함께 작동할 수 있습니다. 구글링을 해보세요, 이것, 이것, 이것 또는 심지어 이것을 찾을 수 있을 것입니다. Redux의 일반적인 아이디어는 어디에나 적용됩니다!

Redux를 현명하게 사용하는 한 React 앱뿐만 아니라 많은 상황에서 이점을 얻을 수 있습니다.

결론

모든 도구와 마찬가지로 Redux는 절충안을 제공합니다. 강력한 기능을 제공하지만 피할 수 없는 단점도 있습니다. 개발 팀의 임무는 절충안이 가치가 있는지 평가하고 의식적인 결정을 내리는 것입니다.

디자이너로서 Redux의 장점과 단점을 이해한다면 디자인의 관점에서 이러한 의사 결정에 기여할 수 있을 것입니다. 예를 들어 잠재적인 성능 영향을 완화하도록 UI를 설계할 수 있습니까? 확인 대화 상자의 부하를 제거하기 위해 실행 취소/다시 실행 기능을 포함하는 것을 옹호할 수 있을까요? 상대적으로 저렴한 비용으로 사용자 경험을 개선하기 때문에 낙관적인 UI를 제안할 수 있을까요?

기술의 장점과 한계를 이해하고 그에 따라 설계합니다. 스티브 잡스가 말한 "디자인이 작동하는 방식"이 아닐까 생각합니다.