데이터 바인딩이란
단방향 데이터 바인딩
- state(Model)이 변할 때, View(유저의 화면)도 함께 변하는 것을 뜻한다.
state 변경 -> View 변경
양방향 데이터 바인딩
- Model이 변할 때, View가 변할 뿐 아니라 View에서 Model의 값을 바꿀 수도 있다는 것을 뜻한다.
state 변경 -> View 변경
View 변경 -> state 변경
ReactJS에서의 데이터 바인딩
ReactJS에서의 데이터 바인딩은 기존의 것과 조금 다르게 해석된다.
이는 props가 흐르는 방향으로 설명되기 때문이다.
부모(상위) 컴포넌트와 자식(하위) 컴포넌트의 state를 하위 컴포넌트에서 사용해야 할 경우, 두 컴포넌트 사이에 존재하는 모든 컴포넌트의 매개변수(props)에 원하는 state나 함수를 담아 하위 컴포넌트로 내려주어야한다.
즉, props가 위에서 아래로 흐르는 구조를 가지게 된다. 따라서, ReactJS는 단방향 데이터 바인딩 구조로 보는 시각이 일반적이다.
양방향 아닌가요?
문득 이야기를 들어보면 ReactJS에선 단방향 바인딩의 양상을 갖는 것 같지만, 이에 대해 반박하는 사례들이 존재한다.
상위 state를 변경할 수 있는 modifier(set함수)를 하위 컴포넌트의 props에 담아 전달해주면, 하위 컴포넌트에서 원하는 값을 전달받아 props로 전달받은 상위 컴포넌트의 modifier를 이용하는 것이 가능하기 때문이다.
const Parent = () => {
const [data, setData] = useState('');
return <Child data={data} setData={setData}/>
}
const Child = ({data, setData}) => {
setData((prev) => '새로운 데이터입니다');
return <div>child</div>;
}하지만, modifier이 부모 컴포넌트로부터 온 것이기 때문에 단방향 데이터 바인딩으로 보는 것이 보편적이다.
문제점 : 엄청난 의존성 발생
- 자식 컴포넌트에서 부모 컴포넌트의 state를 바꾸기 위해선 props를 이용해 modifier를 전달해주어야한다.
- 100번째 자식에게 props를 전달하기 위해선 그 사이의 모든 컴포넌트들의 props에 데이터를 하향적으로 전달해주어야 한다.(props drilling)
위의 특징들 때문에 아래의 문제들이 발생한다.
- 부모 컴포넌트와 100번째 컴포넌트 사이에 있는 모든 컴포넌트들에 의존성 발생.
- 중간 컴포넌트에선 해당 props. 즉, 매개변수의 역할을 알 수 없다. 그저 아래로 전달할 뿐.
- 가독성 저해 및 유지보수 난이도 증가.
왜 이런 문제가 발생할까?
왜 이렇게 불편해야하지?
무엇이 이 문제의 원인이지?
스스로 내린 해답은 다음과 같다.
-
하나의 함수(함수형 컴포넌트)가 두 개의 layer(View, Model)를 책임지고 있기 때문이다. (인터페이스 분리 원칙 위배)
-
하나의 함수가 여러가지 역할(화면 렌더링, 데이터 전달, 데이터 저장 등)을 하고 있기 때문이다. (SOLID 단일 책임 원칙 위배)
상태관리 툴이 해결하는군!
즉, 작성하는 모든 코드에서 기술부채가 발생할 수 있다는 의미이다. 이에 대한 해결책으로 state를 View(컴포넌트)에서 분리시켜낸 것이 상태관리 툴이라고 볼 수 있다.
상태관리 툴은 View와 Model을 분리함으로써 문제를 해결한다.
상태관리 도구를 사용하는 이유는 많겠지만, 직접 피부로 느낀 이유는 위와 같은 이유이다. View와 Model을 분리하고 함수형 컴포넌트들을 순수함수화 하는데 큰 도움을 준다.
각 컴포넌트들은 state로부터 해방된다. 그저 state를 DI받고, 결과를 렌더링만 하는 View의 정체성을 확립하게 된 것이다.
