Redux : 프론트 엔드 애플리케이션 상태 트리가있는 백엔드 DB 동기화

Question

내 경험에 비추어 볼 때, 백엔드 DB와 프론트 엔드 상태 트리를 동기화 상태로 유지하는 것은 앱이 복잡 해짐에 따라 중요하지 않은 작업이됩니다. 당신은 블로그에 새 Post를 만들 때

예를 들어

는, 당신은 DB의 개체를 만들뿐만 아니라 국가 트리 (예. 내부의 게시물 감속기)에 post 객체를 첨부해야합니다. 상태 트리가 중첩되어 있으면 더 복잡해집니다. 게시물에 속한 주석을 업데이트하는 경우 상태 트리에서 올바른 게시물을 찾고 올바른 주석을 찾고 업데이트해야합니다.

나는 응용 프로그램 상태 트리을 사용하는 것이 왜 유익한 지 이해하지만이 동기화로 인해 Redux를 진정으로 높이 평가하는 데 너무 많은 오버 헤드가 발생합니다.

더 쉽게 동기화 할 수있는 방법이 있습니까?

Answer 1

Meteor는 언급 한 문제를 해결하기 위해 특별히 설계되었습니다.

Redux는 클라이언트에서만 상태를 관리합니다. 좀더 정확하게 말하자면, ui 자체에 필요한 상태를 유지하는 것입니다.

종종 React와 함께 사용되어 UI를 렌더링하는 데 필요한 모든 것을 숨기는 스마트 한 장소로 사용됩니다. 여기에는 종종 복잡한 상태가 포함되며 많은 앱 데이터가 포함될 수 있습니다. 그런 다음 데이터베이스처럼 보이기 시작할 수도 있지만 데이터베이스에는 Redux에없는 많은 속성이 있습니다. 지속성이 마음에 온다.

유성은 프레임 워크이며 Redux는 아니다. 따라서 Meteor는 Meteor가 앱에서 많은 수의 문제를 처리하는 방법을 결정할 때 막대한 금액의 바이 인을 제공합니다. 반면 Redux는 매우 관대합니다. 주 (state)가 어떻게 보이는지, 백엔드 (backend)와 어떻게 대화하는지, Ui를 렌더링하는 방법은 결정하지 않습니다.

Redux는 이러한 문제를 어떻게 처리 할 것인지 자유롭게 결정할 수 있으므로, 그렇게해야 할 책임도 있습니다. Redux는 초소형이며 당신은 단단한 국가 관리만을 기대해야합니다.

클라이언트로 이전하는 글로벌 앱 상태는 전적으로 귀하에게 달려 있으며, 백엔드에 연결하는 방법과이 백엔드에서 node.js + Mongo 또는 php + mysql 또는 lisp + 텍스트 파일이 실행되는 경우 전적으로 당신에게 달려 있습니다. 유성을 사용할 때도 마찬가지입니다.

위대한 힘은 큰 책임입니다.