플럭스 패턴 이해

나는 실제로 플럭스 패턴을 연구하고 있으며 상점 과 관련하여 이해할 수없는 것이 있습니다 .

그들은 정확히 무엇입니까?

많은 기사를 읽었으며 도메인과 관련이있는 것 같습니다.

이것이 API 호출 또는 백엔드 호출과 관련된 "추상적 인"부분임을 의미합니까?

나에게는 분명하지 않습니다.

편집 : 각도 공장과 동일한 것일 수 있습니까? 원격 데이터를 가져 와서 비즈니스 작업을하거나 일부 앱 상태를 저장하고 있습니까 (예 : 현재 사용자가 연결된 경우)

좋아, 단계별로 설명해 드리겠습니다

1 플럭스 란?

• 패턴
• 중앙 집중식 디스패처
• 단방향 데이터 흐름
• 목록 항목

그들은 이유도 플럭스라고 부릅니다.

플럭스 구현

• 페이스 북 플럭스
• Alt
• 환류
• 실패
• 핵 JS
• 유동성

플럭스와의 대화

반응 : 이봐 요, 누군가“코스 저장”버튼을 클릭했습니다.

조치 : 감사합니다! 디스패처에 작업 작성자를 등록 했으므로 디스패처는 모든 상점에 해당 사실을 알리도록주의해야합니다.

디스패처 : 코스가 저장되는 것을 누가 신경 쓰는지 봅시다. 아! 스토어에서 나와 콜백을 등록한 것 같습니다. 알려 드리겠습니다.

점포 : Hi dispatcher! 업데이트 해 주셔서 감사합니다! 전송 한 페이로드로 데이터를 업데이트하겠습니다. 그런 다음 관심있는 React 구성 요소에 대한 이벤트를 생성합니다.

반응 : 우! 상점에서 빛나는 새로운 데이터! 이것을 반영하여 UI를 업데이트하겠습니다!

플럭스 API

register (function callback) –“이메일 발송자, 조치가 발생하면 나를 실행하십시오. -저장"

unregister (string id) –“이메일 발송자,이 작업에 대해 걱정하지 마십시오. -저장"

waitFor (array ids) –“이 상점을 먼저 업데이트하십시오. -저장"

dispatch (object payload) -“이 발송자, 상점에이 조치에 대해 알리십시오. -동작"

isDispatching () –“지금 콜백을 발송 중입니다.”

그래서 우리의 마음에서 제기되는 문제는

Flux는 Publish-Subscribe 모델입니까?

좀 빠지는.

두 가지 방법으로 다릅니다.

1. 모든 페이로드가 등록 된 모든 콜백으로 발송됩니다.

2. 콜백은 다른 콜백을 기다릴 수 있습니다

요약

플럭스는 단방향 데이터 흐름의 패턴입니다. 조치 이벤트를 캡슐화합니다. 디스패처는 콜백을 보유하는 중앙 허브입니다. 상점은 앱 상태를 보유합니다. 많은 구현

간단한 예 ( https://github.com/facebook/flux/tree/master/examples/flux-todomvc/ )를 찾아 보면 "상점은 애플리케이션 내의 특정 도메인에 대한 애플리케이션 상태를 관리합니다." 애플리케이션 측면의 상태에 대한 데이터 및이를 변경하는 모든 코드 Dispatcher에서 새 업데이트가있을 때마다 모든 상점에서이를보고 응답으로 데이터를 업데이트하는 방법을 결정한 후 데이터가 변경되었음을보기에 알립니다. 예에서 Stores에는 "보이지 않은 스레드 목록"(Dispatcher가 새 메시지가 도착했거나 이전 메시지를 읽었 음을 알리고 뷰에 메시지 스레드가 사용자에게 표시됨) 및 "현재 재생 시간" 상태."

보다 기술적으로는 업데이트를 받기 위해 디스패처에 콜백을 등록한 다음 데이터 상태가 변경 될 때 뷰에 알리는 프레임 워크의 중간 계층입니다. (뷰는 Dispatcher로 조치를 다시 보낼 수 있습니다.) 각 상점이 Dispatcher에 콜백을 등록하고 이벤트를 Views에 브로드 캐스트하는 추상 인터페이스가 있습니다. 그러나 각 상점은 구체적인 도메인을 구체적인 방식으로 나타냅니다. (반대 예가 있습니까?)

저장소는 응용 프로그램 상태와 복잡한 논리를 저장하는 코드 영역입니다. 여러보기가 동일한 데이터를 사용하지만 다른 방식으로 표시하거나 특정 도메인에 대한 일부 데이터를 표시하거나 일부 데이터를 표시하기 때문입니다. 예를 들어, 사용자가 로그인하면 이름, 성, 이메일, 사진, 도시, 주소, 전화 번호 등이 수신됩니다.이 정보는 별도의보기에 표시됩니다. 여러 뷰에서 데이터를 복제하는 대신 사용자 데이터를 저장하는 UserStore라는 하나의 Store를 사용할 수 있습니다. 이것은 저장된 로직이나 데이터를 변경해야 할 때마다 "변경할 수있는 한 곳"을 제공함으로써 시스템을 단순화합니다. 스토어를 사용해야하는 다른 많은 이유가 있지만, 이것이 제가 생각하는 가장 명백한 것입니다.