리액트 포탈과 렌더링 고민

컨텍스트를 포탈로 감싸는게 flux 패턴을 위함일까?
기존의 provider 방식과 무슨 차이를 가질까?

 

 

렌더링 측면에서 관련없다. 포탈로 context를 제공한다고 해도 각 상태값이 렌더링 되는건 기존의 context api와 차이가 없다. context을 제공하는데 portal을 활용하는게 아니라 portal을 공통으로 제공하는데 context를 활용하는 측면이 있다. 그 역은 성립하지 않는다. (라고 설명을 들었다.) 개인적으로 영감을 느낀 부분이 조금 있어서 해당 부분을 상태관리에 활용할 방법을 고민해봐야겠다.

DOM트리를 벗어나는 설계를 한 이유는 그냥 모바일 특유의 네비게이션 이 목적으로 보인다. UI 특징에 

상단 해더와 하단 버튼등 해당 레이아웃을 포탈을 통해서 컨테이너 컴포넌트 내부에서 관리하면서 컨테이너 외부로 끄집어 낼 경우 해더나 버튼 등의 UI가 컨텐츠 내부의 css 및 레이아웃에 영향 받지 않고 늘 일정한 위치에 배치 할 수 있다는 측면 정도가 생각 해낼 수 있는 장점이다.

여러 루트를 통한 렌더링은 어떤 장점을 가질까?

 

render와 포탈 두가지 방식 모두 여러 root에 App이나 컴포넌트를 다양한 방식으로 제공 할 수 있다. 그렇다면 해당 방법을 통해서 서비스를 구성하는 방식은 어떤 장점이 있을까? 포탈의 경우 컴포넌트 수준에서 그치지만 render의 경우 웹앱 자체를 제공 할 수 있는데(실제로는 리액트 컴포넌트 집합에 불과하니) 리액트 렌더러 내부의 상황이나 성능 같은 측면이 궁금하긴하다. 그리고 해당 부분들을 모두 통합해서 하나의 엔터프라이즈 앱처럼 작동하게 하는 컨셉은 어떨까?