티스토리 뷰
발생일: 2015.05.10
키워드: Flux, React, Stores, Actions, Components, 리액트, 플럭스, 스토어, 액션
문제:
이번에 영어사전 익스텐션을 Angular에서 Flux + React로 변경하려고 한다.
Flux 아키텍처의 사용 패턴이 아직 명확하게 정리되진 않은 것 같아서, 어떤 패턴이 좋을 지 계속 살펴보고 있다.
여전히, 스토어의 역할을 어느 범위까지 잡을지, 어떤 범위까지의 작업을 액션으로 나눌지 좀 애매하다.
아직 좀 더 고민해봐야겠지만,
일단 지금까지 살펴본 내용으로, 아키텍처를 잡을 때 몇 가지 유용한 팁들을 정리해봤다.
해결책:
Stores
- 한 개의 스토어엔 한 가지 타입만 갖도록 한다. 애플리케이션 내에서는 해당 타입을 갖는 스토어는 한 개만 되도록 유지한다.
- 스토어는 다른 데이터와의 관계를 가질 수도 있다. 예를 들어, ‘사용자 목록’ 스토어가 있다면, ‘즐겨찾는 사용자 목록’ 스토어를 두어도 좋다. 단, ‘즐겨찾는 사용자 목록’에서는 사용자의 전체 데이터 대신, 아이디만 참조로 갖도록 한다. (관계형 데이터베이스처럼 말이다)
- 위의 경우처럼, 한 스토어가 다른 스토어를 의존하는 경우, dispatcher 의 `waitFor()` 메서드를 사용한다.
- 스토어에 불완전한 데이터를 저장하는 건 이후에 문제를 일으킬 여지가 있다. 예를 들어, 메시지 목록에 포함된 사용자 데이터를 UserStore가 아닌 MessageStore 에 저장하는 것처럼 말이다. 이런 경우엔, 참조할 아이디만 갖도록 하는 것이 좋다.
- 스토어는 데이터 뿐만 아니라, 애플리케이션의 상태도 가질 수 있다. 예를 들어, 모달 레이어가 보여졌는지 여부나 사용자가 온라인인지 오프라인인지 여부 등처럼 말이다.
- 서버에서 직접 데이터를 패치하는 로직은 스토어가 갖는 것이 더 나을 수 있다. 캐싱이나 필터링 등의 후처리가 필요할 때, 액션에서 패치하는 것보다 스토어에서 처리하는 것이 더 편리하기 때문이다. 반면, 데이터 쓰기 작업은 액션으로 처리하는 쪽이 더 명확하다.
Actions
- 액션은 뷰에서 일어나는 액션과 서버에서 일어나는 액션, 두 가지 타입을 갖도록 한다. 이렇게 하면 사용자 인터랙션과 서버와의 인터랙션을 쉽게 구분할 수 있다.
- 액션은 콜백을 갖지 않도록 한다. (fire and forgot) 콜백이 필요하다면, 액션을 처리 단계마다 발생하는 방법으로 우회할 수 있다. 예를 들어, 요청을 보내는 경우라면, ‘요청', ‘요청성공’, ‘요청실패' 액션을 별도로 정의하는 것처럼 말이다.
- 액션에 컨텍스트 객체를 추가로 정의하는 것이 요긴할 수도 있다. 같은 액션일 지라도 컨텍스트에 따라 업데이트 여부를 판단할 수 있기 때문이다.
Components
- 리액트의 컨벤션을 따른다. 상위 컴포넌트가 상태를 갖고, 하위 컴포넌트가 상태에 따라 렌더링 되는 구조 말이다.
- 상태를 갖고 있는 컴포넌트는 스토어를 참조할 수 있다. 한 개의 컴포넌트가 여러 개의 스토어를 가지는 건 문제가 되지 않는다.
- 스토어의 이벤트를 받을 때 믹스인을 사용하면 편리하다.
참고:
반응형
댓글
공지사항