[WEB] FE에서의 상태 관리
in WEB on Web
1. FE에서 상태 관리란?
프론트앤드에서 상태 관리가 왜 중요해졌을까?
javascript의 발전으로 SSR에서 CSR로 넘어오면서, 브라우저에서 렌더링을 처리하게 되었다.
이때, 상태에 따라 DOM이 결정된다. 즉 DOM이 변하는 경우는 상태에 종속되는 것이다.
상태 관리가 중요해지면서 Redux와 같은 상태 관리 라이브러리가 등장했는데, 사실 이 역사는
jQuery > AngularJS > Redux 의 발전 과정을 거쳤다.
각각을 간단히 살펴보면서, 현재 왜 Redux가 상태 관리 라이브러리로 주목받는지를 알아보자.
2. jQuery와 상태 관리
jQuery 개발은 html에 jQuery를 바르면서 진행된다.
기본 베이스는 html인 것이 핵심이다.
DOM이 동작의 주체가 되며 DOM에 상태가 저장된다.
(data-attribute에 상태 저장) > 왜? 이 DOM과 전혀 상관없는 다른 동작에서도 해당 DOM의 상태값을 가져오기 위해
만약 B의 동작 처리 중(A,B,C의 상태를 변화시켜야 함) A의 상태가 변했다면 그걸 추적할 수 있는가? NO
- jQuery 개발은 DOM에 jQuery로 동작을 입히는 것
- DOM이 베이스
- 각 Element에 상태를 저장
- 서로 다른 Element의 상태변화 추적이 어렵다.
3. AngularJS와 상태 관리
jQuery 방식은 (DOM 제어 방식)은 변경이 필요한 대상 DOM 요소를 먼저 선택하고, 이후 필요한 작업을 수행하는 형태로 진행하는 반면, AngularJS는 출력할 데이터에 초점을 맞추어 작업이 수행되며, 데이터의 값이 변경되면 출력도 자동적으로 수행되도록 처리된다.
- 기본적으로 모듈이라는 개념을 사용 (컴포넌트와 비슷한 개념)
- 컨트롤러라는 지시자를 이용하여 마크업 상에 영역 생성
<div ng-controller="MyController">
Your name: <input type="text" ng-model="username" />
<button ng-click="sayHello()">greet</button>
</div>;
angular.module('scoreExample', []).controller('MyController', [
'$scope',
function ($scope) {
$scope.username = 'World';
$scope.sayHello = function () {
$scope.greeting = 'Hello' + $scope.username + '!';
};
},
]);
DOM에 접근하지 않았는데, 상태에 따라 값이 바뀐다!
각각의 VIEW가 있고 이 VIEW는 controller와 state가 있고, 공통으로 쓰이는 것은 service에 state가 있다.
만약 B의 동작 처리 중(A,B,C의 상태를 변화시켜야 함) A의 상태가 변했다면 그걸 추적할 수 있는가? NO
하지만 jQuery와 비교했을 때, 버그를 확인할 수 있는 부분과 범위가 줄어든다. > 언제와 왜는 찾기 어렵지만 어디서인지는 찾을 수 있다.
4. Redux 와 상태 관리
상태(데이터)를 언제, 왜, 어떻게 변화했는지 알기 위해 사용
FLUX + CQRS + Event Sourcing = Redux
FLUX : 데이터가 단방향으로 흘러가는 것 (View에서 Store를 직접적으로 못바꾼다)
CQRS : 상태를 읽는 것과, 수정하는 것을 분리하는 것
Event Sourcing : 상태를 바꾸고 싶으면 event를 날려서 로그를 남겨라
Action > Middleware > Reducer > Store > View > Action
Store는 읽기 전용의 값이다. 값을 변경할 수 없고 새로 갈아준다.
View는 함수형 프로그래밍의 순수함수처럼 순수한 컴포넌트로, 어떠한 상태가 와도 똑같은 결과값을 준다.
모든 상태변화는 Action을 통해 이뤄지기 때문에 로그가 남고 상태변화 추적이 가능해진다.
문제점은?
- 너무 많은 보일러플레이트가 있다. (action, dispach … 만들게 많아 > 코드가 장황해져)
- 과한 기술일수도 있다. 간단한 프로젝트라면 jQuery가 더 좋을지도..!
- action 처리를 위한 switch-case 에 걸릴 action name 처리가 귀찮다.
Mobx
- 액션, 리듀서 구현 안해도 되서 보일러플레이트가 간단해진다.
- 디버깅이 어렵다.
