2021. 12. 4. 09:29ㆍ카테고리 없음
프론트엔드 개발에서 상태 관리는 매우 중요한 개념입니다. 상태 관리를 통해 사용자 인터페이스(UI)의 상태를 관리하고 변경사항을 추적하고, 애플리케이션의 동적인 요소를 효과적으로 제어해 사용자 경험을 향상시킬 수 있습니다.
프론트엔드에서 가장 일반적인 상태 관리 방법 중 하나는 상태 관리 라이브러리를 사용하는 것입니다. 대표적인 상태 관리 라이브러리로는 Redux, MobX, Vuex 등이 있습니다. 이러한 라이브러리는 애플리케이션의 상태를 중앙 집중화된 저장소에 저장하고, 상태의 변경을 관리하며, 컴포넌트 간의 상태 공유를 용이하게 해줍니다.
Redux는 가장 널리 사용되는 상태 관리 라이브러리 중 하나로, 단방향 데이터 흐름을 기반으로 합니다. Redux는 액션(Action), 상태(State), 리듀서(Reducer)라는 핵심 개념을 가지고 있습니다. 액션은 상태 변경을 위해 디스패치되는 객체이고, 리듀서는 액션을 받아서 실제로 상태를 변경하는 함수입니다. 이를 통해 예측 가능하고 일관된 상태 관리를 할 수 있습니다.
기존 리액트 애플리케이션에서는 상태 관리를 위해 Redux나 Flux와 같은 중앙 집중식 아키텍처를 사용하는 것이 일반적이었습니다. 그러나 이러한 중앙 집중식 아키텍처는 액션과 리듀서를 작성하는 번거로움과 복잡성을 동반하고 있었습니다. 상태를 변경하는 모든 액션과 그에 따른 리듀서를 일일히 정의해야 했고, 상태 갱신을 위해 많은 보일러플레이트 코드를 작성해야 했습니다.
이런 리액트 생태계에서 상태 관리의 복잡성과 번거로움을 해결하고자 Mobx가 등장하게 되었습니다. 복잡한 상태 관리를 단순화하고 개발자들이 더욱 효율적으로 애플리케이션을 개발할 수 있도록 직관적이고 효율적인 방식 의 상태 관리를 제공합니다.
이후 React 애플리케이션에서도 자체적으로 내장된 상태 관리 기능을 사용할 수 있게 되었습니다. useState와 useEffect 훅을 이용하여 상태를 관리하고, 컴포넌트의 생명주기를 활용하여 상태 변경에 대한 사이드 이펙트를 처리할 수 있습니다. 또한 useContext 훅을 사용하여 상위 컴포넌트에서 전역적으로 상태를 공유할 수도 있습니다.
마지막으로, 최신 상태 관리 패턴 중 하나인 상태 관리 컴포넌트 라이브러리인 Recoil도 있습니다. Recoil은 React 애플리케이션에서 간단하게 상태를 관리할 수 있는 기능을 제공합니다. Atom, Selector, RecoilRoot와 같은 개념을 사용하여 컴포넌트 간의 상태 공유와 변경을 처리할 수 있습니다.
프론트엔드 상태 관리를 제공하기 위한 다양한 도구가 존재하며, 프로젝트의 요구사항과 개발자의 선호도에 따라 다른 상태관리 라이브러리 선택이 필요합니다. 앞서 언급한 Redux, React의 내장 상태 관리, Recoil이 그 중 일부이며, 프로젝트의 맞게 상태 관리 도구를 선택하는 것이 중요합니다. 현재 사용 중인 상태 관리 툴을 고도화해 나가는 것, 혹은 개발 cost를 고려해 Recoil이나 다른 상태 관리 라이브러리를 도입하는 것에 대해 고려해볼 가치가 있다고 생각합니다.
Q1. Redux를 기피하는 개발자들이 많은 이유는 무엇일까?
1. Redux는 상태 관리를 위해 많은 개념과 구조를 도입하기 때문에 복잡성과 러닝 커브가 높다는 단점이 있습니다. 작은 규모의 프로젝트에서 상태 관리를 적용하기 위해 액션, 리듀서, 미들웨어 등의 개념을 이해하고 도입하는 것은 비효율적일 수 있습니다.
2. 위와 비슷한 맥락으로 Redux의 많은 보일링플레이트가 단점으로 지적됩니다. Redux를 사용하면 액션 타입, 액션 생성자, 리듀서 등 많은 코드를 작성해야 합니다. 이는 초기 설정과 유지 보수에 부담을 줄 수 있습니다.
Q2. 비교적 최근에 등장한 Recoil은 무조건적으로 좋나요?
1. 성숙도측면에서는 여전히 사용자들의 피드백과 개발을 통해 성장중인 라이브러리입니다. 따라서 일부 사용자들은 아직 충분히 검증되지 않은 라이브러리라고 보거나, 안정성과 신뢰성에 대한 우려를 가질 수 있습니다.
2. Redux와 비교했을 때, Recoil은 아직까지 Redux와 같은 다양한 확장성과 플러그인 생태계를 갖추지 못했습니다. 또한 문서화 및 자료의 부족, 생태계의 제한성의 이유로 특정한 기능이나 플러그인을 사용하고자 할 때 선택의 폭이 제한될 수 있으며, 트러블 슈팅에 어려움을 겪을 수 있습니다.
Q3. Recoil과 Redux 각각의 장단점이 궁금합니다.
Redux
1. 리덕스는 리덕스는 상태 관리를 중앙화된 저장소에 저장하고 관리하기 때문에, 큰 규모의 애플리케이션에 적합합니다. 또한 미들웨어를 사용하여 액션과 리듀서 사이에서 작업을 수행할 수 있습니다. 이를 통해 비동기 작업 처리, 로깅, 에러 핸들링 등을 유연하게 구현할 수 있습니다.
2. 상태 변화를 추적하고 debugging하는데 유용합니다. 또한, 리듀서 함수가 순수 함수로 작성되어 있어 액션과 상태의 독립성이 보장되기 때문에 단위 테스트와 통합 테스트를 작성하기 용이합니다.
3. 리덕스는 다양한 미들웨어와 플러그인을 제공하며, 커뮤니티에서 활발히 사용되고 있기 때문에 개발자들은 리덕스를 활용하여 다양한 기능과 툴을 사용할 수 있습니다.
4. Redux는 상태를 중앙화된 저장소에 저장하고 관리하는 방식을 채택하며, 컴포넌트는 단순히 상태를 읽거나 구독하는 역할을 수행하기 때문에 리덕스 자체적으로는 메모리 누수 문제가 발생하지 않습니다.
Recoil
리코일은 컴포넌트 기반의 상태 관리를 위한 새로운 접근 방식을 제공하며, 많은 개발자들이 사용하고 있습니다. 그러나 모든 상태 관리 라이브러리와 마찬가지로 리코일도 특정 상황에서 메모리 누수 문제가 발생할 수 있으므로, 이를 유의하고 주의하여 사용하는 것이 좋습니다.
1. 리코일에서는 상태를 읽거나 구독하는 컴포넌트는 해당 상태에 대한 변경 사항을 감지하고 업데이트합니다. 그러나 경우에 따라 컴포넌트가 구독을 취소하지 않고 계속해서 상태 변경을 감지하는 경우가 있을 수 있습니다. 이는 메모리 누수로 이어질 수 있습니다.
2. 컴포넌트 해제 문제가 발생할 수 있습니다. 리코일은 컴포넌트가 상태를 읽거나 구독하는 동안 해당 컴포넌트를 추적하는데, 컴포넌트가 적절하게 해제되지 않는다면 리코일은 해당 컴포넌트를 메모리에 유지하게된다면 장기간에 걸쳐 메모리 누수를 초래할 수 있습니다.
3. 리코일은 계속해서 업데이트되고 개선되는 라이브러리이기 때문에 이전 버전에서 발견된 메모리 누수 문제들과 관련된 이슈와 버그 보고를 확인하 가능한 한 최신 버전을 사용하는 것이 좋습니다.
4. Recoil은 분산 상태 관리 라이브러리입니다. 컴포넌트 수준에서 상태를 관리하므로 중앙 집중식 아키텍처에 비해 상태 업데이트와 관련된 코드의 양을 줄일 수 있고, 상태 관리를 보다 직관적이고 유연하게 만들어주는 특징을 가집니다.
Posted by Ang