🤹🏼‍♀️

Module & State Management

Module, State Management 알아야 하는 이유

자바스크립트의 코드의 재사용성을 높이고 싶다면 자바스크립트로 Module로 구분했을 때 데이터의 상태관리를 일관되게 하고 싶다면

이 문서를 보고 나면

자바스크립트로 어플리케이션을 만들 때 모듈 단위로 분리할 수 있다.

상태관리를 위해 가장 중요한 개념인 일관성과 상태접근 범위에 대해 이야기해볼 수 있다.

Module

자바스크립트에서 코드를 로드할 때 "모든 것을 공유하는" 방식은 가장 에러가 발생하기 쉬운 부분이고 언어적으로도 혼란스러운 부분입니다. 다른 언어들은 코드의 스코프를 정의하기 위해 패키지 같은 개념을 갖고 있지만, ES6 이전까지 자바스크립트 파일에 정의된 애플리케이션의 모든 부분은 하나의 전역 스코프를 공유했습니다. 그리고 웹 애플리케이션이 복잡해질수록 더 많은 자바스크립트 코드를 사용하게 되었고, 이러한 방식은 이름 충돌이나, 보안상 우려되는 문제들을 일으켰습니다. ES6의 목표 중 하나는 이러한 문제를 해결하는 것이었고 Module이 등장했습니다.

모듈은 특정 기능을 하는 하나의 코드 묶음 단위입니다. 모듈이 모여 하나의 큰 프로그램이 되며, 모듈은 또 다른 모듈의 일부로서 기능을 할 수 있습니다. 이런 모듈의 핵심은 "캡슐화" 입니다. 모듈 안의 모든 기능은 모듈 안에서 동작하며, 모듈 밖에서는 접근이 허용된 속성이나 메서드만 사용할 수 있도록 허용됩니다. ES5까지는 모듈에 대한 지원이 되지 않았기 때문에, 모듈과 비슷한 구조를 즉시 실행 함수를 이용해 구현했습니다.

const module = (function() {
  const _str = "모듈 변수"
  return {
    myfunc: function() {
      return _str
    }
  }
})()
console.log(module.myfunc())
// 모듈 변수
JavaScript
복사

반환 받은 객체는 myfunc 메서드를 호출할 수 있고, 클로저이기 때문에 _str 변수에 접근할 수 있습니다. 따라서 module.myfunc()를 실행하면 "모듈 변수" 문자열을 반환 받게 됩니다. 모듈 외부에서는 _str 변수에 접근할 수 없습니다.

이러한 방식으로 구현하며 모듈 형태에 대한 니즈가 있다 보니, 결국 ES6에서는 본격적으로 모듈을 지원하게 되었습니다. (ES6의 모듈이 나오기까지 표준을 위한 움직임을 자세히 알아보고 싶다면 링크를 확인해주세요!) 구현 방법이 심플하고 명확하므로 가능하면 위와 같은 방식보다는 ES6의 새로운 모듈 작성 방법을 추천하는데요. ES6에서 새롭게 지원하는 모듈 시스템은 다음의 규칙에 따라 작성합니다.

모듈은 파일 단위로 구성하는 걸 기본으로 한다. 하지만 간단한 메서드 형태인 모듈들인 경우 한 개의 파일에서 관리하기도 한다. 모듈의 변수, 함수, 클래스 등은 export 키워드로 노출하고 import로 다른 모듈, 페이지에서 가져와서 사용한다. 모듈은 순환 참조를 할 수 없다. 모듈 시스템은 항상 트리 구조로 맨 위에 처음 실행되는 루트 페이지/모듈이 있으며 한 방향으로만 참조할 수 있다. 모듈의 이름은 중복될 수 없다. 따라서 가져오는(import) 시점에 이름을 재정의해 충돌을 피할 수 있다.

상태란

프론트엔드 프로그래밍을 하면서 상태(state)관리라는 용어를 많이 쓰는데요. 상태란 쉽게 말하면 '데이터' 라고 생각하면 좋을 것 같습니다. 이 상태 관리는 어플리케이션이 복잡해질수록 점점 어려워집니다. 그렇기 때문에 단순한 구조일때부터 이 상태를 어떻게 관리하면 좋을지에 대한 고민을 충분히 해보는 것은 더 큰 어플리케이션을 만들기 위한 과정에서 중요합니다.

먼저 상태란 무엇일까요? 상태가 있고, 상태가 아닌 것이 있을텐데요. 둘은 어떤 차이가 있을까요? 상태에서 중요한 부분은 바로 값이 변한다는 것입니다. 이 값이 변하는데 예측된 값으로 변해야 의도한대로 동작을 수행할 수 있으니, 예측 범위 안에서 변하게 하는 것이 중요합니다. 그래서 그 예측된 범위를 만들기 위해서, 여러가지 제약조건이나 구조적인 설계를 고민할 수 있습니다.

이 예측 범위를 최소화 하기 위해서는 상태에 대해 일관되게 READ하는 로직과, 최소화한 Write하는 로직을 만들 때 가능해집니다.

범위를 최소화하는거는 모듈 단위, 스코프 단위에 대한 고민으로 확장될 수 있습니다. 상태에 대한 일관성은 상태를 여러 곳에서 같은 방식으로 READ하는 방식을 고민해볼 수 있습니다. 상태를 여러 곳에서 직접적으로 수정한다면, 상태를 예측하고 관리하기 어려우니 수정하는 부분을 제한하고, 그 책임을 가지고 있는 대상이 분명하게 역할을 가진다면 최소화한 write가 가능해질 수 있습니다.

예제를 통해서 프론트엔드의 상태 관리에 대해 알아볼텐데요. 아주 간단한 투두리스트를 통해 상태 관리에 대해 다뤄볼 예정입니다.

위 TodoList 앱은 TodoItems라는 데이터 값을 가집니다. 그런데 이 데이터를 여러군데에서 관리한다면 한 곳에 변화가 있을 때마다, 모든 변화를 감지하고 반영하려면 중복 코드도 많아지고 불필요한 dom 접근 또한 많아질 수 있습니다. 그렇다면 이 데이터를 어떻게, 어디서 관리하면 좋을까요?

우선 데이터와 관련된 부분들을 체크하기 위해 앞의 문서에서 보았던 것처럼 데이터를 가지고 갱신되야 하는 기준으로 UI를 분리해보겠습니다.

더 세부적으로 분리할 수 도 있지만, 우선은 이 4가지로 분리해볼건데요. 위처럼 구분하고 나면, TodoApp이라는 컴포넌트 안에 TodoInput, TodoList, TodoCount UI들이 포함되어 있습니다.

이러한 구조에서 데이터를 효율적으로 주고 받기 위해서는 고려해야할 것은 무엇이 있을까요? 그리고 데이터를 공유하기 위한 효율적인 방법은 무엇일까요? 데이터를 관리하기 위한 방법들을 검색해보셔도 좋고, 스스로 고민한 방법을 직접 구현해봐도 좋을 것 같습니다. 처음부터 잘 만들어진 패턴들을 바로 사용하기 보다는 직접 고민해보고, 구현해보는 과정이 있다면 새로운 기술과 도구들을 만났을 때 그 의미를 더욱 잘 알 수 있습니다. 이러한 부분을 고려해서 로또 미션에 반영해주세요.

위 예제로 연습해보고 싶다면!

링크에서 fork받아 저수준에서부터 추상화시켜나가며 상태관리를 연습해볼 수 있습니다. 만약 작성하고 난 다음에는 PR을 보내보세요! 누군가가 여러분의 PR에 리뷰를 남겨줄꺼에요!

정리

자바스크립트의 상태 관리를 위해 일관되게, 상태에 대해 접근할 수 있는 범위를 고려해야 한다. 바로 잘 정리된 디자인 패턴이나, 라이브러리를 참고할 수도 있지만 스스로 고민해보고 찾아본다면 그러한 도구들의 철학을 더 잘 이해할 수 있고, 기술의 활용도도 더 높아질 수 있다.

참고 링크

•

MDN_자바스크립트_모듈

•

build-a-state-management-system-with-vanilla-javascript