Context로 상태 생명주기 관리

비고
Tags
상태 관리
Select

무지성 글로벌 상태!

  • 여러 화면에서 사용돼야 한다.
  • 한 화면 내에서도 여러 컴포넌트에서 써야 한다.
  • 프롭 드릴링을 할 수 없어!
어떤 판단을 내리시나요?
일반적으로 쉽게 글로벌 상태를 떠올립니다. 실제로 그렇게 많이 쓰고 있고요.
가장 대표적인 것이 Redux이고, 아직도 대부분 Redux 사용습관을 버리지 못했어요.
익숙해졌고, 편하니까요.
 
무지성 글로벌 상태를 쓰지 말라고 얘기할 거니까, 무지성 글로벌 상태의 문제점을 하나씩 이야기 해봅시다.

1. 상태값 관리 로직이 추가되어야 함

  • 필요없어지는 부분에서 reset 시켜주는 로직을 추가해야함
    • 이미 사용이 끝났고, 과거의 데이터가 되었는데 이를 참조해서 잘못된 행위를 할 수 있으므로

2. 의도치 않은 곳에서, 의도치 않은 동작이!?

1에서 파생되는 부분이다.
reset 하는 과정이 어떤 과정인가? 결국엔 상태 값을 변경하는 로직이다!
따라서 상태가 변경되었으니, 해당 상태값을 참조하고 있는 모든 부분에서 리컨사일레이션이 발생한다.
불필요한 행위가 수행되는 것이지 않은가!? 그렇다면 잘못 쓰고 있다는 뜻이다!
 
불필요하게 리컨사일레이션이 동작하게 된다는 것도 불쾌한데,
잘못된 상태값을 참조해서 잘못된 로직이 동작할 수도 있다는 위험이 존재한다.
이런 경우 일반적으로 값이 무엇인지를 검사하는 조건문이 들어가게 된다.
이 또한 얼마나 불필요한 로직인가?!

3. 불필요하게 차지하는 메모리!

사용하지도 않을 데이터를 계속 가지고 있어야 한다.
메모리가 풍족하다고? 그래서 상관없다고?
넥스트 스텝을 추구하지 않는 자에게 더 나은 처우란 없다.
 
물리 디바이스를 만들어서 판매하는 회사 입장에서는 마진을 위해 문제 없는 선에서 최대한 성능을 낮추려고 한다.
담당 개발자는 1차적으로 각종 최적화를 적절하게 녹여내야 하고, 그랬을 때에도 도저히 방법이 없을 경우에만 경영진에게 근거를 들이밀며 사양 업그레이드를 요구할 수 있다.
 
사양이 빵빵한 경우라도, 사용자에게 1초라도 더 빠른 속도와 경험을 선사해서 차이를 보여줘야 하지 않은가?