Remix의 데이터 플로우[Data Flow in Remix]

Remix를 사용하면 상태관리 도구가 왜 필요 없는지 알아봅니다.

TLDR : Action이 발생할 때마다 변경된 데이터를 Loader를 통해 Component에 반영해주면 되기 때문입니다.
해당 로직은 서버에서 동작하므로 동기화에 대해 걱정할 필요도 없습니다.

원문 링크입니다 : https://remix.run/blog/remix-data-flow

Data Flow in Remix

React가 처음 등장했을 때 가장 매력적인 점 중 하나는 "단방향 데이터 흐름(one-way data flow)"이었습니다.
이것은 “Thinking in React”문서에 여전히 설명되어 있습니다.

계층 구조의 맨 위에 있는 컴포넌트는 데이터 모델을 Props로 사용합니다.
컴포넌트의 데이터 모델을 변경하고 root.render()를 다시 호출하면 UI가 업데이트됩니다.
UI가 업데이트되는 방식과 변경 사항을 확인할 수 있습니다.
React의 단방향 데이터 흐름(단방향 바인딩이라고도 함)은 리액트의 모든 것을 모듈화하고 빠르게 동작합니다.

데이터가 앱에서 단방향으로만 흐를 수 있으므로 앱을 훨씬 직관적이고 쉽게 이해하고 추론할 수 있습니다.

데이터가 앱에서 단방향으로만 흐를 수 있으므로 앱을 훨씬 직관적이고 쉽게 이해하고 추론할 수 있습니다.

ui = fn(state)
“UI는 상태의 함수이다”,

 

이 단방향 데이터 흐름은 “UI는 상태의 함수이다”,

즉 ui = fn(state)이라는 문구로 요약되었습니다.

일부 상태가 변경될 때마다 액션에 의해 뷰가 다시 렌더링 됩니다.

지금까지 이 멘탈 모델을 이용하여 애플리케이션 구축을 용이하게 하기 위해 정교한 "상태 관리" 솔루션이 많이 만들어졌습니다.

미묘한 문제는 이 "단방향 데이터 흐름"이 약간 잘못된 이름이라는 것입니다.

정확하게는 클라이언트의 단방향 데이터 흐름입니다.

클라이언트를 위한 데이터만 보유하는 것은 거의 실용적이지 않습니다.

대부분의 경우 서버와의 동기화가 필요한 데이터를 유지해야 합니다.

즉, 두 가지 방식으로 데이터가 흐를 필요가 있습니다.

• 클라애언트 내 단방향 데이터 르흠
• 서버와 클라이언트 간 ??? 데이터 흐름

대부분의 경우 서버와의 동기화가 필요한 데이터를 유지해야 합니다.

많은 상태 관리 도구는 클라이언트의 상태를 관리하는 데만 도움이 되지만
클라이언트의 상태와 서버의 상태 사이의 간격인 네트워크 틈(the network chasm)을 효과적으로 건너는 데 도움이 되지 않습니다.

서버와 클라이언트 간의 데이터 흐름은 단방향??

리믹스를 만나세요! (Enter Remix) 

Remix의 주요 기능 중 하나는 서버와의 상호 작용을 단순화하여 데이터를 컴포넌트로 가져오는 것입니다.

Remix는 네트워크 전체의 데이터 흐름을 확장하여

서버(state)에서 클라이언트(view)로, 그리고 다시 서버(action)로 진정한 단방향 순환형으로 만듭니다.

서버(state)에서 클라이언트(view)로, 그리고 다시 서버(action)로의 진정한 단방향 순환

 

"UI는 상태의 함수"를 좀더 구체적으로 진술하는 방법은 다음과 같습니다.

UI는 원격 상태와 로컬 상태의 함수입니다. 
UI is a function of your remote state and your local state.

 

기존 React 앱에서 모든 상태는 클라이언트에 있으며 유지하려는 부분은 "단방향 데이터 흐름"을 벗어나

네트워크를 통해 서버로 동기화되어야 합니다.

상상할 수 있듯이 이곳은 버그가 발생하기 쉬운 영역입니다.

 

그러나 Remix에서는 원격 상태가 로컬 상태에서 더 쉽게 풀릴 수 있기 때문에
"상태의 함수로서의 UI"라는 개념이 변형되었습니다.

원격 상태는 사용자 데이터와 같이 영속되어야 하는 모든 데이터입니다.

이 상태(예: 사용자에게 읽지 않은 알림이 몇 개나 있습니까?)는 클라이언트에 저장되어,

loaders 및 actions과 같은 Remix 메커니즘을 이용해 조정(reconciles)됩니다.

(참고: Remix는 transitions 및 fetchers를 통한 영구 데이터 전송에 대한 상태 정보를 제공하여 네트워크 틈을 건너는 데 도움이 됩니다. 직접 isLoading과 같은 부울 또는 initial | loading | success | failed 와 같은 열거형 플래그를 이용해

모든 네트워크 요청의 상태를 직접 추적할 필요가 없습니다.)

 

대조적으로, 로컬 상태는 사용자 경험에 부정적인 영향을 미치지 않으면서 손실될 수 있는 임시 데이터입니다(예: 새로 고침을 통해).

즉 손실되어도 사용자 경혐에 영향을 크게 미치지 않습니다.

이 로컬 상태(예: 사용자의 알림을 표시하는 드롭다운이 열려 있습니까?)는

React 상태 또는 로컬 저장소와 같은 메커니즘을 통해 클라이언트에 저장됩니다.

중요한 것은 네트워크 전체에서 영속하고 동기화할 필요가 없으므로 복잡성과 버그 가능성이 감소한다는 것입니다.

앱과 네트워크를 통과하는 순환형 단방향 데이터 흐름

Forms, fetcher, loader, actions, 이것들은 모두 Remix의 "상태 관리" 솔루션입니다.

(우리가 이 도구들을 상태 관리 도구라 부르지 않는다 하더라도,)

리믹스는 클라이언트와 서버 간의 동기화 상태를 지속적으로 유지하는 도구를 제공하여

로더(서버)에서 컴포넌트(클라이언트)에서 액션(서버)에서 다시 로더(서버)로 흐르는,

앱과 네트워크를 통과하는 순환형 단방향 데이터 흐름을 보장합니다.

로더(서버)에서 컴포넌트(클라이언트)에서 액션(서버)에서 다시 로더(서버)로 흐르는, 앱과 네트워크를 통과하는 순환형 단방향 데이터 흐름

Remix를 사용하면 UI가 로컬뿐만 아니라 네트워크 전체의 상태 함수가 됩니다.
Remix의 데이터 추상화에 대한 흥미로운 비유(interesting analogy)는 React의 가상 DOM 추상화입니다.

 

React에서는 DOM을 직접 업데이트하는 것을 신경쓰지 않아도 됩니다.
상태가 설정/변경되면 가상 DOM이 DOM을 효율적으로 업데이트하는 방법을 알아내기 위해 모든 작업을 수행합니다.
Remix는 이 아이디어를 영속 데이터용 API 계층으로 확장합니다.

 

Remix에서는 클라이언트 측 상태를 서버와 동기화하는 것에 대해 걱정하지 않아도 됩니다.
변이(mutation)로 "상태를 변경"하면 로더가 인계받아 최신 데이터를 다시 가져오고 컴포넌트 view를 업데이트합니다.

액샨을 통해 서버 상태가 변경되면, 로더가 동작합니다!

이 게시물이 Remix가 더 나은 웹사이트를 구축하는 데 필요한 복잡성을 줄이는 데 어떤 역할을 하는지 이해하는데 도움이 되었으면 합니다.

Kent가 RenderATL에서 말했듯이,(his talk at RenderATL)

Remix는 JavaScript보다 먼저 동작하기 때문에 점진적 향상으로 지원되는 경험을 얻을 수 있어 당신 앱의 사용자에게 좋습니다.

더욱이 전통적인 상태 관리 솔루션과 결합된 모든 복잡성을 구축할 필요가 없기 때문에 개발자로서도 이득입니다.

Remix를 사용하면, 애플리케이션 상태 관리에 대해 걱정할 필요가 없습니다.
Redux, Apollo는 매우 훌륭한 도구이지만 Remix를 사용할 때 필요하지 않습니다.
클라이언트 측 JavaScript가 전혀 필요하지 않기 때문입니다.
당신의 앱을 생각해보세요. 그리고 상태 관리에 필요한 모든 코드를 버릴 수 있다고 상상해 보세요.
Remix와 함께라면 가능합니다.
브라우저에서 앱이 JavaScript 없이 작동할 수 있다면
브라우저엔 상태 관리를 위한 어떤 코드도 필요하지 않습니다.