들어가기 전에
이번 시간에는 리덕스를 쓰면 좋은 이유를 살펴보겠습니다.
이번 시간에는 리덕스가 기존의 개발환경에 가져온 혁신적인 요소를 보는 것이 아닙니다.
리덕스와 같은 시스템들이 공통적으로 제공하는 혁명적인 내용을 살펴보는 것입니다.
다른 시스템들도 제공하지만 리덕스도 제공하고 있고 리덕스와 같은 시스템을 쓰는 가장 중요한 이유를 살펴보겠습니다.
학습목표
리덕스의 장점을 이해하고 리덕스를 사용하는 이유를 알 수 있습니다.
강의 듣기
들어가기 전에
이번 시간에는 리덕스를 쓰면 좋은 이유를 살펴보겠습니다.
이번 시간에는 리덕스가 기존의 개발환경에 가져온 혁신적인 요소를 보는 것이 아닙니다.
리덕스와 같은 시스템들이 공통적으로 제공하는 혁명적인 내용을 살펴보는 것입니다.
다른 시스템들도 제공하지만 리덕스도 제공하고 있고 리덕스와 같은 시스템을 쓰는 가장 중요한 이유를 살펴보겠습니다.
학습목표
리덕스의 장점을 이해하고 리덕스를 사용하는 이유를 알 수 있습니다.
강의 듣기
이번 시간에는 리덕스를 쓰면 좋은 이유를 알아보겠습니다.
우리 수업에서는 위 그림과 같이 생긴 애플리케이션을 만들 것입니다.
리덕스를 사용하지 않았을 때와 리덕스를 도입했을 때 애플리케이션을 만드는사람의 입장에서
얼마나 생각할 것이 줄어드는 지를 보여주기 위한 사례입니다.
이 애플리케이션은 red 영역에 해당하는 부품의 버튼을 클릭했을 때 나머지 부품들의 색깔도 바꿔줍니다.
마찬가지로 orange 를 클릭하면 나머지 부품들의 색깔을orange로 바꿔 주는 부품의 구현하는 방법을
리덕스를 쓰지 않고 생각하기 쉬운 방법으로 만드는 방법과 리덕스를 도입해서 훨씬 단순한 코드로
훨씬 복잡한 일을 할 수 있도록 해 주는 법을 비교하면서 리덕스를 쓰는 이유를 생각해보겠습니다.
각각의 부품들을 단순화 시켜보도록 하겠습니다.
부품이 하나가 있으면 별 문제가 없습니다. 하지만 부품 두개가 있고 이 두개의 부품은 서로 상호 작용한다고 생각해봅시다.
한 버튼을 클릭하면 다른 버튼의 색깔도 바뀐다면 버튼을 클릭했을 때
다른 부품의 색깔을 바꾸는 로직과 자신의 색깔도 바꾸는 로직이 필요합니다.
즉 각각의 부품은 2개씩 로직이 필요하므로 총 4개의 로직이 필요합니다.
만약 부품이 2개 더 늘어나서 4개가 된다면 한 부품 당 4개의 로직이 필요하므로 전체 16개 로직이 필요합니다.
부품이 하나 추가될 때마다 작업해야 될 것은 기하급수적으로 늘어나고 있습니다.
만약 우리의 부품 100개라면 10000개의 로직을 작성해야 됩니다.
우리가 어떤 부품을 추가하는 것이 뿐만 아니라 추가되어 있는 것을 빼는 것도 굉장히 어렵습니다.
예를 들어서 한 부품을 지운다고 하면 그 부품을 지우는 것으로 해결되는 것이 아니라
그 부품을 알고 있는 다른 부품들이 있기 때문에 지우려고 시도했다가 실패하게 되고 프로그램이 죽어버리게 됩니다.
즉 각각의 부품들이 서로에게 강하게 연결되어 있기 때문에 여러 가지 문제를 갖게 됩니다.
소프트웨어가 유연하고 할 수 없습니다.
리덕스를 도입해보겠습니다. 가운데 있는 것이 리덕스 store입니다.
만약에 버튼을 클릭해서 상태가 바뀐다면 이 버튼이 리덕스의 store 에 데이터가 어떻게 달라졌는지를 알려주는 코드가 필요합니다.
즉 로직이 하나가 더 있어야 합니다.
그 후 store는 자신을 구독하고 있는 모든 부품들에게 "상태가 바뀌었으니 알아서 업데이트 하세요" 라고 알려줍니다.
각각의 부품들은 상태가 바뀌었을 때 자기가 자신을 어떻게 변화시켜야 되는지에 대해서 알고 있기 때문에 알아서 업데이트 됩니다.
각각의 부품들은 몇 개 로직이 필요한가요?
상태가 바뀐 것을 알려줄 수 있는 로직과 상태가 변경 됐을 때 자기 자신을 변화시키는 것에 대한 로직, 총 두 개가 필요합니다.
따라서 부품이 4개라면 총 8개에 로직이 필요합니다.
이전에 우리가 살펴보았던 어 최초의 모델은 컴포넌트가 100 개면 로직이 10000개가 필요합니다.
하지만 이젠 컴포넌트가 100개면 200개의 로직이 필요합니다. 훨씬 더 애플리케이션이 단순해지는 효과를 볼 수 있습니다.
뿐만 아니라 리덕스는 시간여행을 할 수 있습니다.
"Redux Dev Tool" 이라는 것을 설치해 실행을 시켜 보겠습니다
크롬의 개발자 도구의 확장기능을 설치하면 리덕스 라는 항목이 추가가 됩니다
링크를 클릭해서 애플리케이션의 상태를 바꾸면 store 안에 있는 state 에 어떤 변화가 생기는지를 보여줍니다.
create 버튼을 누르면 change_mode가 되고 submit을 누르면 state의 상태가 바뀐 이력들을 보여줍니다.
애플리케이션 의 상태에 대한 버전 관리를 하는 것이라고 생각할 수도 있습니다.
각각의 상태들을 클릭해보면 어떤 변화가 있었는지를 볼 수 있습니다.
아래 play 버튼을 누르면 애플리케이션 처음 시작했을 때부터 했었던 모든 일들을 재생시켜주며 언제든지 과거로 돌아갈 수 있습니다.
time traveling 이라고 하는 시간여행 도구를 이용하면 각각의 변화가 생겼을 때
애플리케이션이 내부적으로 어떤 상태인지를 볼 수 있고 현재 애플리케이션 의 상태를 파일로 다운로드 받아서
import 해주는 것을 통해 애플리케이션은 상태가 그대로 복원됩니다.
그래서 리덕스 를 사용했을 때 좋은 점은 중앙 집중적인 DATA STORE를 통해서 애플리케이션을 쉽게 바로 개발할 수 있다는 것과
리덕스만이 가지고 있는 시간 여행을 할 수 있다는 기능입니다.
생각해보기
리덕스를 사용할 때 좋은 점을 설명해보세요.