현장은 이렇습니다
이러한 작업은 동시에 여러 모델에 의존해야 하므로 특정 모델에서는 이러한 코드가 작성되지 않습니다.
예를 들어 ViewController로 작성된 Backbone일 수 있습니다... 하지만 이는 코드 재사용에 좋지 않으며 View가 엉망이 됩니다.
현재 해결 방법은 단일 파일을 사용하여 대부분의 모델 작업을 수집하는 것이지만 문제는 이 파일의 크기가 계속 커지고 복잡해진다는 것입니다.
그렇다면 이러한 문제는 어떻게 해결해야 할까요?
추가 질문은 이 코드 부분을 어떻게 구성할 것인가입니다.
예를 들어 React의 Flux 솔루션을 사용해서 프로세스를 명확하게 하려고 했는데, 이 부분의 코드를 어디에 넣어야 할지 모르겠다는 걸 발견했습니다..
Flux는 사용자 작업을 작업으로 변환하고 Store는 Dispatcher를 통해 이러한 작업을 모니터링합니다.
하나의 작업이 여러 Store에 해당하면... 문제가 발생합니다:
스토어에 각각 대응하기 위해 여러 작업을 사용해야 합니까, 아니면 하나의 작업을 여러 스토어에서 모니터링해야 합니까?
曾经蜡笔没有小新2017-05-16 17:08:22
사용자가 버튼을 클릭하는 것은 본질적으로 사용자가 URL을 통해 액세스하는 것과 동일합니다. 이는 "입력"이므로 문제 및 처리 메커니즘은 동일합니다. 뷰 레이어 코드에서 "입력"을 모니터링하고 일부 뷰를 처리합니다. 레이어(예: 버튼 구성 요소) 토글, URL 수정) 내부 상태 변경, 순수하고 더 높은 추상화 수준(뷰 구성 요소 또는 URL 세부 정보와 관련 없음) 데이터/메시지 생성/추출, 일종의 이벤트 메커니즘을 사용하여 브로드캐스트한 다음 , 컨트롤러 레이어가 있는 경우 코드의 이 부분에서 이러한 이벤트를 수신하고 해당 모델 개체의 메서드를 호출합니다(모델 개체 자체 간의 종속성과 호출을 캡슐화할 수 있지만). 여기서 일대다 복잡성은 외부에 노출되지 않습니다. 또한 특정 모델 객체의 상태 변경을 모니터링하고 해당 뷰 객체의 메서드를 호출합니다(또는 Virtual DOM을 다시 렌더링합니다). 모든 것이 묶여 있습니다.
예를 들어 저는 보통 NervJS(모델) + DermJS(뷰) + URLKit(라우트)의 조합을 사용합니다. NervJS 및 DermJS 개체에는 자체 이벤트 메서드가 있습니다. 또한 뷰/ 모델 객체가 초기화되었습니다.
UI 컴포넌트를 작성할 때, 물론 특정 모델에 의존하는 것을 원하지 않을 것입니다. 모델 컴포넌트를 작성할 때, 일대일 바인딩과 같은 바인딩을 사용하는 것이 좋습니다. -많은 작업이 다른 위치에 있습니다(특히 비즈니스 로직 코드). 뷰 개체와 모델 개체는 서로 몇 개이고 어떤 개체가 있는지 알 필요가 없으므로 "여러 작업이 각각 Store에 해당합니다." ".
"단일 파일"과 "지속적으로 커지는 혼란"의 문제는 라우팅 파일 구성과 동일합니다. 관련 경험을 참고하세요.
曾经蜡笔没有小新2017-05-16 17:08:22
플럭스에서는 여러 매장에 대응하기 위해 하나의 조치가 필요한 경우 실제로 해결하기 쉽습니다.
스토어에 콜백을 등록할 때 이 액션에 응답할 수 있으며, waitFor
를 통해 해당 순서를 변경할 수도 있습니다. waitFor
来改变相应的顺序。
如果担心代码变乱的话,可以再单独写一个constants
文件,定义好触发的事件名称就可以了。
举个例子:
点击一个按钮,触发send
事件,会更新两个Store
分别是StoreA
和StoreB
。可以写一个constants.js
,先定义事件名称:
constants:
module.exports = {
"ActionTypes": {
"SEND": "SEND"
}
};
然后在两个Store
里面分别注册回调:
StoreA:
var AppDispatcher = require('path/to/disp'),
constants = require('path/to/constants');
StoreA.dispatchToken = AppDispatcher.register(function(payload) {
var action = payload.action;
if (action.type === constants.ActionTypes.SEND) {
// callback A
};
});
StoreB:
var AppDispatcher = require('path/to/disp'),
constants = require('path/to/constants');
StoreB.dispatchToken = AppDispatcher.register(function(payload) {
var action = payload.action;
if (action.type === constants.ActionTypes.SEND) {
// callback B
};
});
在触发点击事件的时候,在Action
中触发Disp
的这个事件,就会顺序执行在StoreA
和StoreB
상수
파일을 작성하고 트리거된 이벤트의 이름을 정의할 수 있습니다. 🎜
🎜예: 🎜
🎜버튼을 클릭하면 두 개의 Store
, 즉 StoreA
및 StoreB
가 업데이트되는 send
이벤트가 실행됩니다. constants.js
를 작성하고 먼저 이벤트 이름을 정의할 수 있습니다. 🎜
🎜상수:🎜
으아악
🎜그런 다음 두 개의 Store
에 각각 콜백을 등록합니다. 🎜
🎜A매장:🎜
으아악
🎜B스토어:🎜
으아악
🎜클릭 이벤트가 발생하면 Action
에서 Disp
이벤트가 발생하여 StoreA
, 에서 순차적으로 실행됩니다. StoreB< /code>에 등록된 콜백 :)🎜회신하다0
曾经蜡笔没有小新2017-05-16 17:08:22
본 적이 없거나, 봤지만 잊어버렸다면 읽어 볼 가치가 있는 기사입니다:
대규모 JavaScript 애플리케이션 아키텍처를 위한 패턴
간단히 말하면, 뷰와 모델이 서로 의존할 필요가 없도록(1:1 종속성이든 1:N 종속성이든) "기존의" 뭔가가 필요합니다.
간단한 이벤트 및 관찰자 패턴을 사용할 수도 있습니다. 비즈니스 로직이 복잡하다면 중재자를 사용하여 모듈 간 통신 및 동기화를 완료하세요.
PS: 이상적인 상황은 각 모듈이 자신(어떤 이벤트가 트리거되는지, 어떤 이벤트가 수신되는지)만 알고 상대방의 인스턴스나 중재자의 인스턴스는 말할 것도 없고 다른 어떤 것에도 관심이 없다는 것입니다. .