각도에서JS와 플럭스 연결 - 반응 방식

각도에서JS와 플럭스 연결 - 반응 방식

Hands-on이 좋은 개발자로서 AngularJS 익스피리언스, 리액트를 사용하여 Flux에서 웹 앱을 작성하는 mental model을 어떻게 조정합니까?

저는 플럭스+리액트 vs 앵귤러 답변을 찾고 있지는 않습니다(이미 온라인에서는 많이 있습니다).하지만 두 가지 "마인드셋"의 가장 큰 차이점은 알고 싶습니다.이전에는 앵귤러 웨이(The Angular Way)에 대해 소개받았습니다.비교적으로 리액트 웨이(The React Way)는 무엇입니까?

Angular 우주를 떠나 플럭스로 전환하면서 주목해야 할 주요 사항은 무엇입니까?

먼저 차이점, 그리고 이제 유사점:각진JS는 매우 독단적이고 컨트롤러에 UI/DOM 코드를 넣지 않는 등 매우 큰 거부감을 가지고 있습니다.React의 큰 반대와 의견은 무엇입니까?

마지막으로, 페이스북은 MVC의 대안으로 플럭스를 언급하고 있지만, 내가 보고 있는 바로는 리액트는 뷰 엔진이며, 스토어는 단일 도메인에 초점을 맞춘 모델 컨테이너이며, 디스패처와 액션은 컨트롤러를 형성한다.이거 다른 이름 가진 MVC 아니야?

Angular와 비교/대조를 다른 사람에게 맡기겠습니다만, 여기 두 가지 질문에 대한 답변이 있습니다.

이거 다른 이름 가진 MVC 아니야?

데이터/로직 계층과 뷰 계층 간의 우려 분리가 플럭스에 존재한다고 해서 MVC가 되는 것은 아닙니다.다른 많은 패턴들은 유사한 분할을 가지고 있는데, 특히 CQRS는 거의 틀림없이 플럭스의 가장 가까운 사촌이다.플럭스, MVC 의미에서는 컨트롤러가 없습니다.액션과 디스패처는 컨트롤러에 속하지 않습니다.컨트롤러의 뷰는 비슷하지만 컨트롤러와 같은 측면에서는 상당히 제한적입니다.주요 차이점은 MVC 컨트롤러가 애플리케이션 로직을 포함하고 모델에 따라 작동한다는 것입니다.반면 플럭스 저장소에는 모든 애플리케이션 로직이 포함되어 있으며 설정기가 없습니다.

Angular 우주를 떠나 플럭스로 전환하면서 주목해야 할 주요 사항은 무엇입니까?

플럭스의 주요 값:

• 복잡함보다 심플함.
• 프로그래머의 정신적 모델은 적어도 코드 자체만큼 중요하다.
• 애플리케이션의 일부는 고도로 분리되어야 하며 다른 부분에 대해서는 가능한 한 "알지" 않아야 합니다.
• 제어 반전: 모든 제어는 상태를 관리하는 저장소에 있어야 합니다.상점은 행동하지 않고 오히려 행동으로부터 정보를 얻는다.
• 애플리케이션은 성장에 따라 복원력과 유연성을 유지해야 하며, 새로운 예기치 않은 기능을 보다 빠르고 쉽게 개발할 수 있어야 합니다.

플럭스의 주요 개념:

• → → → → → → →
  • 모든 상태 변경과 모든 새 데이터는 디스패치된 액션으로 시작합니다.
  • 이 4단계 데이터 흐름은 플럭스 프로그래머의 핵심 멘탈 모델입니다.
• 디스패치에 의해 어플리케이션 전체의 상태가 변환됩니다.
  • 이것은 변화의 스냅숏을 만드는 순간입니다.이것은 쉽게 추론할 수긍정할 수 있다.
  • 디스패치 중에는 디스패치를 할 수 없고, 이 단순함을 유지할 수 없습니다.따라서, 결과적인 변경은 원래의 액션에 의해 추진되어야 합니다.
• 플럭스 스토어는 도메인 모델이지 ORM 모델이 아닙니다.애플리케이션 내의 특정 논리 도메인의 모든 로직을 포함하고 모든 상태를 관리합니다.여기에는 컬렉션, 특이값 또는 둘의 조합이 포함될 수 있습니다.
• Flux는 파생 데이터가 모델 또는 저장소가 정규화된 데이터를 관리하는 복잡한 응용 프로그램에서 발생할 수 있는 현상이라고 가정합니다.이 문제를 해결하기 위해 Flux Dispatcher는 매장 내에서 이러한 의존성을 선언적으로 관리하는 메커니즘을 노출해야 합니다.Facebook의 Dispatcher에서는, 이 조작은,waitFor()이를 통해 한 스토어는 자신의 응답을 진행하기 전에 다른 스토어의 액션에 대한 응답을 기다릴 수 있습니다.

플럭스 애플리케이션의 주요 부분:

• 작업: 새 데이터 및 특정 유형을 포함하는 개체 리터럴로, 저장소에서 해당 도메인과 관련이 있는지 여부를 식별할 수 있습니다.
• 디스패처: 콜백을 통해 페이로드(액션)를 등록자(스토어)에게 배포하는 콜백의 레지스트리.그것만의 지능은 없다.모든 정보는 스토어에 있습니다.
• Stores: Dispatcher에 자신을 등록하고 상태가 변경될 때마다 '변경' 이벤트를 내보내는 도메인 모델입니다.
• Controller-views: 컴포넌트 트리의 루트 부근에 있는 컴포넌트를 표시합니다.이들은 상점에서 '변경' 이벤트를 듣고 상점에서 노출된 게터 방식으로 새로운 데이터를 검색하여 자녀에게 전달하는 방식으로 이 이벤트에 대응한다.컨트롤러 뷰와 뷰의 유일한 차이점은 이 리스닝 기능입니다.
• 뷰: 컨트롤러 뷰 컴포넌트의 상태 비저장 하위 컴포넌트. 순수 기능과 마찬가지로 데이터를 수신 및 전달합니다.뷰와 컨트롤러 뷰는 성능 저하 없이 원하는 대로 재렌더할 수 있는 기능을 제공하기 때문에 React를 통해 구현되는 경우가 가장 많습니다.
• 유틸리티: 다른 모듈 간에 쉽게 공유할 수 있는 순수한 기능의 라이브러리.

개요 상세: http://facebook.github.io/flux/docs/overview.html

튜토리얼: http://facebook.github.io/flux/docs/todo-list.html

예: https://github.com/facebook/flux/tree/master/examples

액션 및 디스패처:http://facebook.github.io/react/blog/2014/07/30/flux-actions-and-the-dispatcher.html

테스트: http://facebook.github.io/react/blog/2014/09/24/testing-flux-applications.html

자세한 내용은 http://facebook.github.io/react/blog/2014/10/17/community-roundup-23.html를 참조해 주세요.

언급URL : https://stackoverflow.com/questions/27264487/from-angularjs-to-flux-the-react-way