React Flux 구조 에 대한 이해
개인 현 단계 에서 Flux 구조 에 대한 이 해 는 벽돌 을 두 드 려 스타 를 구 합 니 다!원본 링크:https://github.com/kuitos/kuitos.github.io/issues/27
React 프로필 여기 찍 어 주세요.
Flux 가 뭐 예요?
Flux 는 페 이 스 북 이 클 라 이언 트 웹 애플 리 케 이 션 을 구축 하 는 데 사용 하 는 응용 구조 이다.이것 은 단 방향 데이터 흐름 방식 을 이용 하여 react 의 보기 구성 요 소 를 조합 합 니 다.이것 은 정식 프레임 워 크 가 아 닌 하나의 모델 과 같 습 니 다. 개발 자 는 새로운 코드 를 많이 필요 로 하지 않 아 도 빠르게 Flux 를 시작 할 수 있 습 니 다.
Flux 의 핵심 부분
1. dispatcher
이벤트 스케줄 링 센터, flux 모델 의 중심 허브 로 Flux 응용 중의 모든 데이터 흐름 을 관리 하고 있 습 니 다.그것 은 본질 적 으로 스토어 의 리 셋 등록 이다.모든 Store 는 자신 을 등록 하고 리 셋 함 수 를 제공 합 니 다.Dispatcher 가 Action 에 응답 할 때 등 록 된 리 셋 함 수 를 통 해 Action 이 제공 하 는 데 이 터 를 응용 프로그램의 모든 Store 에 부하 합 니 다.응용 등급 단일 예!!
2. store
패 키 징 응용 을 담당 하 는 업무 논리 와 데이터 의 상호작용.
3. view
4. 기타
action creators 는 dispatcher 의 보조 함수 로 서 보통 Flux 의 네 번 째 부분 이 라 고 볼 수 있 습 니 다.Action Creators 는 상대 적 으로 독립 된 것 으로 문법 적 보조 함수 로 서 action 의 형식 으로 dispatcher 가 데 이 터 를 전달 하 는 데 더욱 편리 합 니 다.
How Flux(Unidirectional Data Flow) Works
// Nav.jsx
export default class Nav extends React.Component {
_handleClick(nav) {
NavActionCreators.clickNav(nav);
}
render() {
let itemList = this.props.list.map((nav, index) => {
return (
{nav.text}
);
});
return (
);
}
}// NavActionCreators.js
export default {
clickNav(nav){
AppDispatcher.dispatch(
{
type: ActionTypes.CLICK_NAV,
nav
}
);
}
};AppDispatcher.register(action => {
switch (action.type) {
// nav
case ActionTypes.CLICK_NAV:
IndexWebAPIUtils.getGiftList(_currentUserInfo.userId, action.nav.id)
.then(function (giftList) {
_currentGiftList = giftList;
IndexStore.emitChange();
});
break;
// no default
}
});export default class Index extends React.Component {
constructor(props) {
super(props);
let currentUser = UserStore.getCurrentUser();
this.state = IndexStore.getAll();
}
componentDidMount() {
IndexStore.addChangeListener(this._onChange.bind(this));
}
componentWillUnmount() {
IndexStore.removeChangeListener(this._onChange.bind(this))
}
_onChange() {
this.setState(IndexStore.getAll());
}
render() {
let state = this.state;
return (
...
);
}
}Flux vs MVVM
MVVM
1. 심 플 한 MVVM
2. 복잡 한 MVC
Flux
1. 복잡 한 Flux
Flux 의 장점
1. 데이터 상태 가 안정 되 고 행동 이 예측 가능
angular 양 방향 연결 의 원인 으로 인해 우 리 는 데이터 가 어느 순간 에 안정 적 인 상태 에 있 는 지 영원히 알 수 없 기 때문에 우 리 는 angular 에서 setTimeout 방식 으로 문 제 를 처리 하 는 것 을 자주 볼 수 있다 (사실은 더욱 우아 한 해결 방안 이 있 고 이번 토론 에 포함 되 지 않 는 다).또한 양 방향 연결 로 인해 행위 의 흐름 도 예측 하기 어렵 습 니 다. 보기 의 model 이 많아 질 때 하위 보기 가 이 model 에 의존 하면 문제 가 발생 할 때 포 지 셔 닝 은 악몽 입 니 다.(이것 도 angular 의 오류 정보 가 그렇게 우호 적 이지 않 은 이유 입 니 다. 프레임 워 크 개발 자 들 도 현재 행동 이 누가 촉발 되 었 는 지 확인 할 수 없 기 때 문 입 니 다. 바 인 딩 하 는 사람 이 너무 많 습 니 다.)그러나 여기 서 강조해 야 할 것 은 양 방향 연결 이 반드시 불안정 한 데이터 상 태 를 초래 하 는 것 이 아니 라 angular 에서 우 리 는 일부 수단 을 통 해 데 이 터 를 안정 시 킬 수 있 습 니 다. 다만 양 방향 연결 (mvvm) 은 flux 보다 데이터 불안정 문 제 를 일 으 키 기 쉽 습 니 다.
2. 모든 데이터 변경 은 store 에서 발생
flux 에서 view 는 store 를 직접 수정 할 수 없습니다. view 가 할 수 있 는 일 은 action 을 실행 한 다음 action 은 dispatcher 를 통 해 마지막 으로 store 로 흘러 갑 니 다. 모든 데이터 변경 은 store 구성 요소 내부 에서 발생 합 니 다. store 는 대외 적 으로 get 인터페이스 만 제공 하고 set 행 위 는 내부 에서 발생 합 니 다. store 에는 모든 관련 데이터 와 업무 논리 가 포함 되 어 있 습 니 다. 모든 store 관련 데이터 처리 논 리 는 집합 되 어 있 습 니 다.업무 논리 가 분산 되 지 않도록 유지 비용 을 낮 춥 니 다.
3. 데이터 렌 더 링 은 위 에서 아래로
view 의 모든 데이터 원본 은 속성 에서 만 전달 되 어야 합 니 다. view 의 모든 표현 은 상부 에서 보 기 를 제어 합 니 다 (controller - view).상태 가 결 정 됩 니 다. controller - view 를 용기 구성 요소 로 이해 할 수 있 습 니 다. 이 용기 구성 요소 에는 작은 하위 구성 요소 가 포함 되 어 있 습 니 다. 용기 구성 요소 의 서로 다른 상태 에 대응 하 는 데이터, 하위 구성 요 소 는 자신의 상태 가 있 을 수 없습니다. 즉, 데 이 터 는 store 에서 controller - view 로 전 달 된 후, controller - view 는 setState 를 통 해 데 이 터 를 속성 으로 위 에서 아래로 전달 합 니 다.키 별 view 를 건 네 줍 니 다.
4. view 층 이 얇 아 지고 진정한 구성 요소 화
2, 3 두 가지 이유 로 view 자체 가 해 야 할 일이 적어 집 니 다. 업무 논 리 는 store 에 의 해 이 루어 졌 고 상태 변경 은 controller - view 에 의 해 이 루어 졌 습 니 다. view 자신 이 해 야 할 일 은 상호작용 에 따라 서로 다른 action 을 촉발 하 는 것 일 뿐 입 니 다. 이 로 인해 전체 view 층 이 얇 아 지고 순수 해 지 며 ui 층 의 상호작용 에 만 관심 을 가지 게 되 었 습 니 다. 각 view 구성 요소 가 완성 되 기 전에.모두 소나무 결합 으로 view 구성 요소 의 재 활용 성 을 크게 향상 시 켰 습 니 다.
5. dispatcher 는 일례 입 니 다.
하나의 응용 프로그램 에 있어 서 dispatcher 는 하나의 예 입 니 다. 가장 중요 한 것 은 dispatcher 는 데이터 의 배포 센터 입 니 다. 모든 데 이 터 는 dispatcher 를 거 쳐 야 합 니 다. dispatcher 는 store 와 다른 action 관 계 를 관리 해 야 합 니 다. 모든 데 이 터 는 dispatcher 에 한 획 을 남 겨 야 하기 때 문 입 니 다. 이 를 바탕 으로 우 리 는 많은 재 미 있 는 일 을 할 수 있 습 니 다. 각종 debug 도구, 동작 스크롤 백, 로그 기록 을 할 수 있 습 니 다.녹음, 심지어 권한 차단 같은 것 도 가능 합 니 다.
Flux 의 곤경
1. 과도 한 모델 코드
flux 는 하나의 구조 모델 일 뿐 이미 실 현 된 프레임 워 크 가 아 닙 니 다. 따라서 이 모델 을 바탕 으로 우 리 는 많은 모델 코드 를 써 야 합 니 다. 코드 량 duang 이 한꺼번에 올 라 왔 습 니 다. 그러나 다행히 현재 flux 기반 의 제3자 가 많이 사용 되 고 있 습 니 다. 현재 가장 핫 한 것 은 redux 입 니 다.
2. dispatcher 는 일례
dispatcher 는 flux 의 이벤트 배포 센터 로 서 모든 store 의 사건 을 관리 해 야 합 니 다. 응용 프로그램 에서 사건 이 많아 지면 사건 순서 관리 가 복잡 해 지고 유지 하기 어렵 습 니 다. dispatcher 가 어떤 store 를 관리 하 는 지 명확 하 게 표현 할 수 있 는 통 일 된 곳 이 없습니다.
3. 비동기 처리 가 어디 에 쓰 여 있 는 지
마지막 에 쓰다
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Thymeleaf 의 일반 양식 제출 과 AJAX 제출텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
