Flux (async)를 사용한 낙관적 업데이트

Question

Flux 모델에 낙관적 업데이트를 추가하려고합니다. UI 액션 디스패치와 서버 액션 디스패치를 ​​하나의 액션으로 끌어 올리고 있습니다. 액션 작성자에 내 코드는 다음과 같습니다

deleteItem: function(itemId) { 

    // optimistic update 
    WebshipDispatcher.handleServerAction({ 
     type: ActionTypes.DELETE_ITEM, 
     deleteStatus: 'success', 
     itemId: itemId 
    }); 

    // now let's actually check if that was the correct result 
    AppAjaxUtil.get('/deleteItem', {itemId: itemId}, function(result) { 

     WebshipDispatcher.handleServerAction({ 
      type: ActionTypes.DELETE_ITEM, 
      deleteStatus: result.status, // 'success' or 'failure' 
      itemId: itemId 
     }); 

    }, function(error) { 

     WebshipDispatcher.handleServerAction({ 
      type: ActionTypes.DELETE_ITEM, 
      error: error 
     }); 

    }); 
} 

이 낙관적 인 업데이트를 허용하거나 내가 잘못이 작품에 대해 생각하고 적절한 방법이 있나요?

Answer 1

@fisherwebdev가 맞습니다. 진정한 논리는 상점에서 발생합니다. 예를 들어 항목 삭제에 실패 할 때 논리를 어떻게 처리합니까? 그건 짐승이되는거야. 서버에서 확인하지 않는 한 상점에서 항목을 제거하고 싶지는 않습니다. Ext와 같은 라이브러리는 서버에서 성공적으로 응답을 기다리는 동안 레코드를 지저분하다고 표시합니다. 따라서 업데이트는 여전히 낙관적 인 일이지만 서버가 실패하면 사용자와 기록에 통지됩니다.

따라서 서버가 응답 할 때 제거되는 상점에 dirty 레코드의 콜렉션이있을 수 있습니다. 이것은 거칠지 만 다음과 같은 내용입니다.

deleteItem: function(itemId) { 

    // optimistic update 
    WebshipDispatcher.handleServerAction({ 
     type: ActionTypes.MARK_ITEM_AS_DIRTY, 
     deleteStatus: 'success', 
     itemId: itemId 
    }); 

    // now let's actually check if that was the correct result 
    AppAjaxUtil.get('/deleteItem', {itemId: itemId}, function(result) { 

     WebshipDispatcher.handleServerAction({ 
      type: result.status ? ActionTypes.DELETE_ITEM : ActionTypes.DELETE_ITEM_FAIL, 
      deleteStatus: result.status, // 'success' or 'failure' 
      itemId: itemId 
     }); 

    }, function(error) { 

     WebshipDispatcher.handleServerAction({ 
      type: ActionTypes.DELETE_ITEM_FAIL, 
      error: error, 
      itemId: itemId 
     }); 

    }); 
} 

기본적으로 응답이 성공적이면 저장소에서 더티 레코드를 제거합니다. 그렇지 않으면 저장소에있는 더티 레코드에 대한 참조가 있습니다.이 레코드는 앱이 실행되는 동안 서버 뒤에서 다시 시도 할 수 있습니다. 따라서 본질적으로 사용자는 앉아서 응답을 기다릴 필요가 없습니다.