기술 면접: Flux 패턴

Flux 패턴에 대해 설명해 주세요

Flux 패턴과 MVC 패턴의 차이점에 대해 설명해 주세요

Flux 패턴의 장점과 단점은 무엇인가요?

Flux 패턴을 구현할 때 어떤 라이브러리를 사용할 수 있나요?

가장 널리 사용 되는 것은 Redux이다. Redux는 Flux 패턴을 기반으로 만들어 졌으며, React와의 통합이 매우 쉬워 많은 개발자들이 사용하고 있다. 그 외에도 Mobx, Fluxible, Reflux등이 있다.

Redux의 작동 원리를 간단하게 설명해 주세요

액션(Action): 액션의 종류와 액션에 필요한 데이터를 전달하는 함수를 생성합니다.
스토어(Store): 애플리케이션의 상태와 액션을 처리하는 로직이 들어있는 객체입니다.
리듀서(Reducer): 이전 상태와 액션을 받아서 다음 상태를 반환하는 함수입니다.
구독(subscribe)과 액션 발생(dispatch): 구독 함수를 통해 상태가 변경될 때마다 호출될 콜백 함수를 등록합니다. 액션 발생 시, 이를 처리하는 리듀서 함수가 호출되고, 새로운 상태가 스토어에 저장됩니다. 이후 등록된 콜백 함수가 호출되어 상태 변경을 반영합니다.
이러한 방식으로 Redux는 단방향 데이터 흐름을 유지하면서, 상태 관리를 보다 예측 가능하고 효율적으로 할 수 있도록 지원합니다.

Flux 패턴에서 요소들의 작동 순서를 설명해주세요

Flux 패턴에서 액션과 이벤트의 차이점은 무엇인가요?

액션: 애플리케이션에서 어떤 변화가 일어났는지를 나타내는 일종의 객체입니다. 액션은 일반적으로 두 개의 속성을 가지고 있습니다. 첫 번째 속성은 "type"으로, 액션의 종류를 나타내는 문자열입니다. 두 번째 속성은 "payload"라고 하며, 액션에 대한 추가적인 정보를 담고 있습니다.
이벤트: Flux 패턴에서 이벤트는 사용자의 입력이나 시스템에서 발생하는 다른 이벤트를 나타냅니다. 이벤트는 액션과는 다르게, 사용자와 상호작용하는 애플리케이션의 일부분입니다. 이벤트는 보통 사용자가 버튼을 클릭하거나 키보드 입력을 하는 등의 동작을 수행할 때 발생합니다.

즉, 액션은 애플리케이션의 내부 상태를 변경하는 데 사용되는 객체이며, 이벤트는 애플리케이션에서 발생하는 외부 동작을 나타내는 것입니다.

Flux 패턴의 문제점의 해결방안

Flux 패턴을 구현하기 위해 어떤 라이브러리를 사용할 수 있나요?

Flux 패턴을 사용할 때 주의해야 할 점은 무엇인가요?

Flux 패턴은 단방향 데이터 흐름을 유지해야 합니다. 따라서, 액션 -> 디스패처 -> 스토어 -> 뷰 -> 액션과 같은 순서로 데이터 흐름이 이루어져야 합니다. 이러한 구조를 유지하지 않으면 애플리케이션의 상태를 예측하기 어려워질 수 있습니다.
이벤트 핸들러 등록에 대한 과용을 지양해야 합니다. Flux 패턴은 React와 같은 뷰 라이브러리와 함께 사용되기 때문에, 이벤트 핸들러 등록을 많이 사용하게 됩니다. 이러한 등록이 지나치게 많아지면 메모리 누수 등의 문제가 발생할 수 있으므로, 주의가 필요합니다.
Flux 패턴은 기본적으로 동기적으로 데이터를 처리합니다. 따라서 비동기 작업을 처리할 때는 액션 큐와 같은 추가적인 기능을 구현해주어야 합니다.
스토어 간 종속성을 올바르게 관리하지 않으면 데이터 흐름에 문제가 발생할 수 있습니다. 스토어 간에 서로 종속적인 상황에서는, 각각의 스토어에서의 데이터 변경이 서로에게 영향을 끼치는 문제가 발생할 수 있습니다. 따라서, 스토어 간의 종속성을 잘 파악하고 관리해주어야 합니다.
Flux 패턴을 사용하면서 코드 구조화가 필요합니다. 애플리케이션 규모가 커지면 코드가 복잡해지고 유지보수가 어려워질 수 있습니다. 이를 방지하기 위해서는 코드를 모듈화하고, 애플리케이션의 전체적인 구조를 잘 파악하고 설계해야 합니다.

 

Flux 패턴의 흐름에 대해 설명해 주세요

View에서 Action이 발생하면 Dispatcher가 이를 수신해 각 Store들에게 순서대로 전달한다.
Action을 전달받은 Store는 관심 있는 Action에 대해 상태를 변경하고 변경된 상태를 View에게 알려줌.
View는 변경된 상태에 따라 화면을 새로 그려줌. 만약 View에서 다른 Action이 발생한다면 이 사이클이 반복.
이러한 엄격한 단방향 데이터 흐름을 통해 Flux는 애플리케이션을 단순하게 유지하고
항상 최신버전의 상태를 View를 통해 보여줄 수 있음.

이러한 흐름에서 Dispatcher는 중앙 집중식으로 액션을 처리하고, Store는 상태를 관리하며, View는 상태를 렌더링합니다. 이러한 단방향 데이터 흐름을 통해 여러 개의 View에서 동시에 상태를 관리할 수 있으며, 상태의 변화를 예측하기 쉽고 디버깅이 용이합니다.
Flux 패턴에서 Store는 변경 가능한 상태를 가지며, 이 상태는 View에서 직접 변경할 수 없습니다. 대신에 View는 Store에서 상태를 가져와서 렌더링합니다. 이로 인해 상태의 불변성을 보장하고, 상태를 변경할 때는 항상 Store를 통해 변경해야 합니다. 이러한 제한을 통해 상태의 예측 가능성을 높이고, 복잡한 상태 관리를 보다 쉽게 할 수 있습니다.

 

Flux 패턴은 어떤 상황에서 적합한가요?

대규모 애플리케이션, 복잡한 데이터 흐름, 서로 다른 컴포넌트 간의 통신, 테스트 용이성, 상태 변화 추적 용이성

Flux 패턴에서 Store는 어떤 역할을 하나요?

Flux 패턴에서 Store는 애플리케이션의 상태와 데이터를 저장하고 관리하는 역할을 합니다.

Store는 애플리케이션의 모든 데이터를 저장하며, 이 데이터는 View에서 직접적으로 접근할 수 없습니다. 대신에, Store는 Dispatcher에서 전달받은 Action을 처리하고, 이에 따라 데이터를 업데이트합니다.
Store는 단방향 데이터 흐름을 따르기 때문에, 데이터의 변화는 항상 Dispatcher를 통해 이루어지며, 이에 따라 View가 업데이트됩니다. 따라서 Store는 단방향 데이터 흐름을 보장하고, 상태 관리를 보다 체계적으로 수행할 수 있도록 합니다.
또한, Flux 패턴에서는 여러 개의 Store를 사용할 수 있습니다. 각각의 Store는 특정한 데이터 집합을 저장하고 관리하며, 이에 따라서 각각의 View에서 필요한 데이터만 가져올 수 있습니다. 이는 애플리케이션의 규모가 커질수록 상태 관리를 보다 효율적으로 수행할 수 있도록 합니다.

Flux 패턴을 사용하여 어플리케이션의 성능을 개선할 수 있나요?

Flux 패턴은 애플리케이션의 성능을 개선하는 데 도움이 될 수 있습니다.

Flux 패턴에서는 상태를 저장하고 변경사항을 감지하기 위해 스토어를 사용합니다. 이때, 스토어에서 데이터 변경을 감지할 때 최적화를 고려해야 합니다. 대부분의 Flux 구현에서는 스토어에 등록된 뷰에 데이터 변경 알림을 보내는데, 이때 변경사항이 있는 부분만 뷰에 전달하도록 최적화해주면 성능을 향상시킬 수 있습니다.

Flux 패턴에서는 디스패처를 통해 액션을 처리하고, 스토어를 업데이트합니다. 이때, 스토어 업데이트를 바로 처리하지 않고, 데이터 변경을 일정 시간 동안 지연시켜주는 방법을 사용할 수 있습니다. 이를 통해 데이터 변경이 일어나는 주기를 줄일 수 있고, 성능을 향상시킬 수 있습니다.
React와 함께 Flux 패턴을 사용할 때는, 불필요한 렌더링을 방지하는 것이 성능 향상에 중요합니다. React에서는 불필요한 렌더링을 방지하기 위해 shouldComponentUpdate 메소드를 제공합니다. 이를 활용하여, 뷰 컴포넌트가 변경된 데이터만 다시 렌더링하도록 최적화해주면 성능을 향상시킬 수 있습니다.
Flux 패턴에서는 비동기 작업을 처리할 때 액션 큐와 같은 추가적인 기능을 구현해야 합니다. 이때, 비동기 작업을 최적화하여 성능을 향상시킬 수 있습니다. 예를 들어, 비동기 작업이 완료되었을 때 스토어 업데이트를 진행하는 것이 아니라, 변경사항을 모아서 일괄 업데이트하는 방법을 사용할 수 있습니다.
큰 규모의 애플리케이션에서는 코드 스플리팅을 통해 초기 로딩 시간을 줄일 수 있습니다. 코드 스플리팅을 활용하여, 초기 로딩 시간을 최소화하고, 필요한 부분만 로드하도록 구현해주면 성능을 향상시킬 수 있습니다.

 

---

Action은 상태 변경 요청을 담은 자바스크립트 객체

•  액션 이름 (type)
•  데이터 (payload)
•  Action 생성자
  •  Action을 쉽게 만들어주는 도우미

 

Dispatcher는 모든 데이터 변경 요청이 경유하는 중앙 허브

•  View로부터 Action을 받아 모든 Store들에게 전송
•  내부에 상태 변경 로직이 존재하지 않음
•  Store 간 의존성 관리
  •  Store A의 상태 변경 순서를 Store B 다음으로 미룰 수 있음

Store는 애플리케이션 상태 및 로직 컨테이너

•  Dispatcher에서 전달된 Action을 통해서만 상태 변경
•  상태가 변경되면 View에게 통지

View는 상태에 따라 화면을 출력하는 로봇

•  Controller-View (React)
  •  Store가 통지하는 상태 변경을 수신, 받은 상태에 따라 View를 새로 렌더링
•  Dispatcher에게 Action 전달

View에서 Action이 발생하면 Dispatcher가 이를 수신해 각 Store들에게 순서대로 전달한다.

Action을 전달받은 Store는 관심 있는 Action에 대해 상태를 변경하고 변경된 상태를 View에게 알려줌.

View는 변경된 상태에 따라 화면을 새로 그려줌. 만약 View에서 다른 Action이 발생한다면 이 사이클이 반복.

이러한 엄격한 단방향 데이터 흐름을 통해 Flux는 애플리케이션을 단순하게 유지하고

항상 최신버전의 상태를 View를 통해 보여줄 수 있음.

 

Flux를 사용하면 데이터 흐름의 구조화 할 수 있다. (유지 보수하기 쉽게 만든다, 새로운 기능 확장이 열려있다)

디스패치는 액션을 받아 상태를 변경하는 순수함수이다. 외부의 상태의 영향을 받지 않기 때문에 쉽게 테스트할 수 있다.

대규모 웹 어플리케이션에서 상태관리를 하기 쉽다.

 

반면에 Flux를 사용하려면 초기에 작은 기능을 정리하기 위해 상대적으로 많은 코드가 필요함.

이는 학습 곡선을 높이고, 개발 시 불 필요한 프로그래밍 오버헤드를 발생시킬 수 있다.

이러한 문제점을 해결하기위해 Redux나 Mobx와 같이 Flux를 발전시킨 다양한 구현 라이브러리들이 등장함.