2016-04-15 23 views
6

Tôi đang sử dụng cùng một biểu mẫu và cùng một trạng thái trong redux để thêm và chỉnh sửa. Khi tôi gọi api để tìm nạp dữ liệu để chỉnh sửa và chúng tôi thay đổi bộ định tuyến của mình để thêm biểu mẫu trước khi phản hồi đến. Tất cả dữ liệu biểu mẫu sẽ được tự động điền để thêm mục vì tôi đang sử dụng cùng một trạng thái cho cả việc thêm và chỉnh sửa. Có cách nào để ngăn chặn điều này xảy ra không?Chúng ta có thể hủy bỏ phản hồi api khi bộ định tuyến phản ứng bị thay đổi không?

tạo hành động của tôi:

fetchById: function (entity, id) { 
     return function (dispatch) { 
      dispatch(apiActions.apiRequest(entity)); 
      return (apiUtil.fetchById(entity, id).then(function (response) { 
        dispatch(apiActions.apiResponse(entity)); 
        dispatch(actions.selectItem(entity, response.body)); 
      } 
     } 
} 

Như phản ứng trễ rồi selectItem được cử muộn. Và khi tôi mở biểu mẫu để thêm mục thì biểu mẫu này được lấp đầy với dữ liệu này từ phản hồi.

Trả lời

3

Thunks nhận cả hai đối số dispatchgetState làm đối số.

Nếu bạn giữ tuyến đường hiện tại ở trạng thái của mình, bạn có thể kiểm tra API gọi lại cho dù bạn vẫn ở trên cùng một trang với getState().routing.path hoặc một cái gì đó như thế này và return nếu nó đã thay đổi kể từ khi cuộc gọi API bắt đầu.

Nếu bạn không giữ lộ trình hiện tại trong tiểu bang, bạn có thể đọc this.context.router trong thành phần của mình (đừng quên xác định contextTypes để tải xuống!) Và chuyển nó cho người tạo hành động. Sau đó, người tạo hành động có thể sử dụng router.isActive() để kiểm tra xem chúng tôi có còn trên cùng một con đường trước và sau yêu cầu hay không.

Cuối cùng, bạn chỉ có thể không sử dụng cùng một trạng thái để chỉnh sửa và thêm mục. Hình dạng trạng thái của bạn có thể trông giống như { drafts: { newItem: ..., 1: ..., 2: ... } } và bạn có thể giữ biểu mẫu “thêm” trong drafts.newItem và giữ bất kỳ biểu mẫu “chỉnh sửa nào” bằng ID của tổ chức tương ứng. Bằng cách này, họ sẽ không bao giờ ghi đè lên nhau và, như một phần thưởng, các chỉnh sửa đang diễn ra có thể được bảo tồn, ví dụ: nếu bạn nhấn "Trở lại" và sau đó đi đến biểu mẫu một lần nữa (tùy thuộc vào việc bạn muốn điều này trong UX của bạn tất nhiên).

+0

Tôi không nghĩ rằng việc kiểm tra tuyến đường mà chúng tôi đang ở là một ý tưởng tốt. Một kịch bản, Nếu chúng tôi nhấp vào chỉnh sửa cho một mục thì chúng tôi sẽ nhanh chóng quay lại và nhấp vào chỉnh sửa mục của mục thứ hai. Nếu đáp ứng cho yêu cầu đầu tiên đến muộn hơn lần thứ hai thì biểu mẫu được lấp đầy với dữ liệu sai ngay cả khi chúng ta đang ở trong cùng một tuyến đường. –

+0

Không chắc chắn lý do tại sao điều đó xảy ra. Tôi cho rằng các mục khác nhau có các tuyến sửa đổi khác nhau, không phải vậy sao? –

+0

Ồ vâng ..Tôi quên phần id .. Cảm ơn tôi sẽ thử nó .. –

1

Tôi đã xem số blog post ngày hôm sau và tôi nghĩ phần thứ hai mô tả những gì bạn đang tìm kiếm. Bạn không nhất thiết muốn hủy yêu cầu nhưng bỏ qua câu trả lời.

Về cơ bản, bạn muốn tạo bộ giảm tốc ngoài sẽ theo dõi yêu cầu không đồng bộ của bạn với máy chủ có id duy nhất. Chỉ khi id yêu cầu nằm trong danh sách thì hãy cho phép nó vào bộ giảm phụ.

Khi bạn chuyển trang, bạn sẽ muốn xóa danh sách các id duy nhất này.

Lifted thẳng từ blog:

const initialState = []; 

function update(state = initialState, action) { 
    const { seqId } = action; 

    if (action.type === constants.UNLOAD) { 
    return initialState; 
    } 
    else if (seqId) { 
    let newState; 
    if (action.status === 'start') { 
     newState = [...state, seqId]; 
    } 
    else if (action.status === 'error' || action.status === 'done') { 
     newState = state.filter(id => id !== seqId); 
    } 

    return newState; 
    } 

    return state; 
} 

và sau đó hạn chế sự gia giảm phụ:

let store = createStore((state, action) => { 
    if (action.seqId && 
     (action.status === 'done' || action.status === 'error') && 
     state && 
     state.asyncRequests.indexOf(action.seqId) === -1) { 
    return state; 
    } 
    return reducer(state, action); 
}); 

Big hét ra James cho việc này. Giải pháp thực sự tốt đẹp và giải thích rất tốt trong bài đăng trên blog của mình.

+0

Tôi đã có ý tưởng cơ bản nhưng tôi không hiểu phần lưu trữ. –

Các vấn đề liên quan