Redux中的排队操作

时间：2016-08-03 11:30:19

标签： javascript reactjs redux

我目前遇到的情况是我需要连续运行Redux Actions。我已经看过各种各样的中间件，比如redux-promise，如果你知道连续动作在根点（缺少一个更好的术语）被触发的行为，这似乎很好 / em>的

基本上，我想维护一个可以随时添加的动作队列。每个对象在其状态中具有该队列的实例，并且相关的动作可以相应地排队，处理和出列。我有一个实现，但这样做我在我的动作创建者中访问状态，这感觉就像一个反模式。

我将尝试提供有关用例和实现的一些背景信息。

用例

假设您要创建一些列表并将其保留在服务器上。在列表创建时，服务器以该列表的id响应，该ID用于与列表相关的后续API端点：

http://my.api.com/v1.0/lists/           // POST returns some id
http://my.api.com/v1.0/lists/<id>/items // API end points include id

想象一下，客户希望对这些API点执行乐观更新，以增强用户体验 - 没有人喜欢看微调器。因此，当您创建列表时，会立即显示新列表，并在添加项目时添加选项：

+-------------+----------+
|  List Name  | Actions  |
+-------------+----------+
| My New List | Add Item |
+-------------+----------+

假设有人在初始创建调用的响应之前尝试添加项目。 items API依赖于id，因此我们知道在拥有该数据之前我们无法调用它。但是，我们可能希望乐观地显示新项目并将对项目API的调用排入队列，以便在创建调用完成后触发它。

潜在解决方案

我目前用来解决这个问题的方法是给每个列表一个动作队列 - 也就是说，将连续触发的Redux动作列表。

列表创建的reducer功能可能如下所示：

case ADD_LIST:
  return {
    id: undefined, // To be filled on server response
    name: action.payload.name,
    actionQueue: []
  }

然后，在动作创建者中，我们将行动排队而不是直接触发它：

export const createListItem = (name) => {
    return (dispatch) => {
        dispatch(addList(name));  // Optimistic action
        dispatch(enqueueListAction(name, backendCreateListAction(name));
    }
}

为简洁起见，假设backendCreateListAction函数调用一个fetch API，它会在成功/失败时将消息从列表中派遣出来。

问题

这里让我担心的是enqueueListAction方法的实现。这是我访问状态以控制队列进度的地方。它看起来像这样（忽略名称上的匹配 - 实际上这实际上使用了clientId，但我试图保持示例简单）：

const enqueueListAction = (name, asyncAction) => {
    return (dispatch, getState) => {
        const state = getState();

        dispatch(enqueue(name, asyncAction));{

        const thisList = state.lists.find((l) => {
            return l.name == name;
        });

        // If there's nothing in the queue then process immediately
        if (thisList.actionQueue.length === 0) {
            asyncAction(dispatch);
        } 
    }
}

这里，假设enqueue方法返回一个普通操作，该操作将异步操作插入到列表actionQueue中。

整个事情感觉有点不利于我，但我不确定是否还有其他方法可以解决这个问题。另外，由于我需要在我的asyncActions中调度，我需要将调度方法传递给它们。

该方法中有类似的代码从列表中出列，如果存在则触发下一个操作：

const dequeueListAction = (name) => {
    return (dispatch, getState) => {
        dispatch(dequeue(name));

        const state = getState();
        const thisList = state.lists.find((l) => {
            return l.name === name;
        });

        // Process next action if exists.
        if (thisList.actionQueue.length > 0) {
            thisList.actionQueue[0].asyncAction(dispatch);
    }
}

一般来说，我可以忍受这种情况，但我担心这是一种反模式，在Redux中可能会有更简洁，惯用的方式。

感谢任何帮助。

5 个答案:

答案 0 :(得分：2)

我有一个完美的工具，可以满足您的需求。当你需要对redux进行大量控制时，（特别是异步的）你需要按顺序执行redux动作，没有比Redux Sagas更好的工具了。它建立在es6生成器之上，为您提供了很多控制，因为从某种意义上说，您可以在某些点暂停代码。

您描述的操作队列就是所谓的传奇。现在，因为它是为了与redux一起使用而创建的，所以可以通过在组件中调度来触发这些传奇。

由于Sagas使用发电机，您还可以确定您的发货按特定顺序发生，并且仅在某些条件下发生。以下是他们的文档中的示例，我将引导您完成它以说明我的意思：

function* loginFlow() {
  while (true) {
    const {user, password} = yield take('LOGIN_REQUEST')
    const token = yield call(authorize, user, password)
    if (token) {
      yield call(Api.storeItem, {token})
      yield take('LOGOUT')
      yield call(Api.clearItem, 'token')
    }
  }
}

好吧，起初看起来有些混乱，但这个传奇定义了登录序列需要发生的确切顺序。由于生成器的性质，允许无限循环。当您的代码进入 yield 时，它将停在该行并等待。在你告诉它之前，它不会继续下一行。所以看看yield take('LOGIN_REQUEST')的位置。此传奇将在此时产生或等待，直到您发送“登录”报告为止。之后，saga将调用授权方法，直到下一次收益。下一个方法是异步yield call(Api.storeItem, {token})，因此在代码解析之前它不会转到下一行。

现在，这就是魔术发生的地方。该传奇将再次停在yield take('LOGOUT')，直到您在应用程序中发送LOGOUT。 这是至关重要的，因为如果你在LOGOUT之前再次发送LOGIN_REQUEST，则不会调用登录过程。现在，如果你发送LOGOUT，它将循环回到第一个yield并等待应用程序发送再次登录_REQUEST。

到目前为止，Redux Sagas是我最喜欢使用Redux的工具之一。它为您提供了对应用程序的如此多的控制权，任何阅读代码的人都会感谢您，因为现在一切都在一行中读取。

答案 1 :(得分：1)

看看这个：https://github.com/gaearon/redux-thunk

单独的id不应该通过减速器。在您的操作创建者（thunk）中，首先获取列表ID，然后然后（）执行第二次调用以将项目添加到列表中。在此之后，您可以根据添加是否成功来分派不同的操作。

您可以在执行此操作时调度多个操作，以报告服务器交互何时开始和结束。这将允许您显示消息或微调器，以防操作繁重并可能需要一段时间。

可以在此处找到更深入的分析：http://redux.js.org/docs/advanced/AsyncActions.html

所有归功于丹·阿布拉莫夫

答案 2 :(得分：0)

您无需处理排队操作。它将隐藏数据流，这将使您的应用程序调试更加繁琐。

我建议您在创建列表或项目时使用一些临时ID，然后在实际从商店收到实际ID时更新这些ID。

这样的事可能吗？ （不要测试，但你得到了id）：

编辑：我一开始并不理解保存列表时需要自动保存的项目。我编辑了createList动作创建者。

/* REDUCERS & ACTIONS */

// this "thunk" action creator is responsible for :
//   - creating the temporary list item in the store with some 
//     generated unique id
//   - dispatching the action to tell the store that a temporary list
//     has been created (optimistic update)
//   - triggering a POST request to save the list in the database
//   - dispatching an action to tell the store the list is correctly
//     saved
//   - triggering a POST request for saving items related to the old
//     list id and triggering the correspondant receiveCreatedItem
//     action
const createList = (name) => {

  const tempList = {
    id: uniqueId(),
    name
  }

  return (dispatch, getState) => {
    dispatch(tempListCreated(tempList))
    FakeListAPI
      .post(tempList)
      .then(list => {
        dispatch(receiveCreatedList(tempList.id, list))

        // when the list is saved we can now safely
        // save the related items since the API
        // certainly need a real list ID to correctly
        // save an item
        const itemsToSave = getState().items.filter(item => item.listId === tempList.id)
        for (let tempItem of itemsToSave) {
          FakeListItemAPI
            .post(tempItem)
            .then(item => dispatch(receiveCreatedItem(tempItem.id, item)))
        }
      )
  }

}

const tempListCreated = (list) => ({
  type: 'TEMP_LIST_CREATED',
  payload: {
    list
  }
})

const receiveCreatedList = (oldId, list) => ({
  type: 'RECEIVE_CREATED_LIST',
  payload: {
    list
  },
  meta: {
    oldId
  }
})


const createItem = (name, listId) => {

  const tempItem = {
    id: uniqueId(),
    name,
    listId
  }

  return (dispatch) => {
    dispatch(tempItemCreated(tempItem))
  }

}

const tempItemCreated = (item) => ({
  type: 'TEMP_ITEM_CREATED',
  payload: {
    item
  }
})

const receiveCreatedItem = (oldId, item) => ({
  type: 'RECEIVE_CREATED_ITEM',
  payload: {
    item
  },
  meta: {
    oldId
  }
})

/* given this state shape :
state = {
  lists: {
    ids: [ 'list1ID', 'list2ID' ],
    byId: {
      'list1ID': {
        id: 'list1ID',
        name: 'list1'
      },
      'list2ID': {
        id: 'list2ID',
        name: 'list2'
      },
    }
    ...
  },
  items: {
    ids: [ 'item1ID','item2ID' ],
    byId: {
      'item1ID': {
        id: 'item1ID',
        name: 'item1',
        listID: 'list1ID'
      },
      'item2ID': {
        id: 'item2ID',
        name: 'item2',
        listID: 'list2ID'
      }
    }
  }
}
*/

// Here i'm using a immediately invoked function just 
// to isolate ids and byId variable to avoid duplicate
// declaration issue since we need them for both
// lists and items reducers
const lists = (() => {
  const ids = (ids = [], action = {}) => ({
    switch (action.type) {
      // when receiving the temporary list
      // we need to add the temporary id 
      // in the ids list
      case 'TEMP_LIST_CREATED':
        return [...ids, action.payload.list.id]

      // when receiving the real list
      // we need to remove the old temporary id
      // and add the real id instead
      case 'RECEIVE_CREATED_LIST':
        return ids
          .filter(id => id !== action.meta.oldId)
          .concat([action.payload.list.id])
      default:
        return ids
    }
  })

  const byId = (byId = {}, action = {}) => ({
    switch (action.type) {
      // same as above, when the the temp list
      // gets created we store it indexed by
      // its temp id
      case 'TEMP_LIST_CREATED':
        return {
          ...byId,
          [action.payload.list.id]: action.payload.list
        }

      // when we receive the real list we first
      // need to remove the old one before
      // adding the real list
      case 'RECEIVE_CREATED_LIST': {
        const {
          [action.meta.oldId]: oldList,
          ...otherLists
        } = byId
        return {
          ...otherLists,
          [action.payload.list.id]: action.payload.list
        }
      }

    }
  })

  return combineReducers({
    ids,
    byId
  })
})()

const items = (() => {
  const ids = (ids = [], action = {}) => ({
    switch (action.type) {
      case 'TEMP_ITEM_CREATED':
        return [...ids, action.payload.item.id]
      case 'RECEIVE_CREATED_ITEM':
        return ids
          .filter(id => id !== action.meta.oldId)
          .concat([action.payload.item.id])
      default:
        return ids
    }
  })

  const byId = (byId = {}, action = {}) => ({
    switch (action.type) {
      case 'TEMP_ITEM_CREATED':
        return {
          ...byId,
          [action.payload.item.id]: action.payload.item
        }
      case 'RECEIVE_CREATED_ITEM': {
        const {
          [action.meta.oldId]: oldList,
          ...otherItems
        } = byId
        return {
          ...otherItems,
          [action.payload.item.id]: action.payload.item
        }
      }

      // when we receive a real list
      // we need to reappropriate all
      // the items that are referring to
      // the old listId to the new one
      case 'RECEIVE_CREATED_LIST': {
        const oldListId = action.meta.oldId
        const newListId = action.payload.list.id
        const _byId = {}
        for (let id of Object.keys(byId)) {
          let item = byId[id]
          _byId[id] = {
            ...item,
            listId: item.listId === oldListId ? newListId : item.listId
          }
        }
        return _byId
      }

    }
  })

  return combineReducers({
    ids,
    byId
  })
})()

const reducer = combineReducers({
  lists,
  items
})

/* REDUCERS & ACTIONS */

答案 3 :(得分：0)

这就是解决这个问题的方法：

确保每个本地列表都有唯一标识符。我不是在谈论后端ID。名称可能不足以识别列表？尚未持久化的“乐观”列表应该是唯一可识别的，并且用户可以尝试创建具有相同名称的2个列表，即使它是边缘情况。

在创建列表时，将后端标识的承诺添加到缓存

CreatedListIdPromiseCache[localListId] = createBackendList({...}).then(list => list.id);

在项目添加上，尝试从Redux商店获取后端ID。如果它不存在，那么尝试从CreatedListIdCache获取它。返回的id必须是异步的，因为CreatedListIdCache返回一个promise。

const getListIdPromise = (localListId,state) => {
  // Get id from already created list
  if ( state.lists[localListId] ) {
    return Promise.resolve(state.lists[localListId].id)
  }
  // Get id from pending list creations
  else if ( CreatedListIdPromiseCache[localListId] ) {
    return CreatedListIdPromiseCache[localListId];
  }
  // Unexpected error
  else {
    return Promise.reject(new Error("Unable to find backend list id for list with local id = " + localListId));
  }
}

在addItem中使用此方法，以便您的addItem会自动延迟，直到后端ID可用

// Create item, but do not attempt creation until we are sure to get a backend id
const backendListItemPromise = getListIdPromise(localListId,reduxState).then(backendListId => {
  return createBackendListItem(backendListId, itemData);
})

// Provide user optimistic feedback even if the item is not yet added to the list
dispatch(addListItemOptimistic());
backendListItemPromise.then(
  backendListItem => dispatch(addListItemCommit()),
  error => dispatch(addListItemRollback())
);

您可能想要清理CreatedListIdPromiseCache，但它对大多数应用程序可能不是很重要，除非您有非常严格的内存使用要求。

另一种选择是后端id在前端计算，类似于UUID。你的后端只需要验证这个id的唯一性。因此，即使后端尚未回复，您仍然会为所有乐观创建的列表提供有效的后端ID。

答案 4 :(得分：0)

我遇到了类似的问题。我需要一个队列来保证将乐观操作提交或最终提交（如果出现网络问题），并按照相同的顺序创建远程服务器，如果不可能则回滚。我发现仅使用Redux，因为我认为它不是为此而设计的，并且只使用promises这样做可能真的是一个难以理解的问题，除了你需要以某种方式管理你的队列状态这一事实。 .. 恕我直言。

我认为@ Pcriulan关于使用redux-saga的建议很好。乍一看，在你到达channels之前，redux-saga并没有提供任何帮助。这为您打开了一扇门来处理其他语言所做的其他语言的并发性，特别是CSP（例如，参见Go或Clojure的async），感谢JS生成器。甚至questions为什么以Saga模式命名，而不是CSP haha​​ ......无论如何。

所以这里是一个传奇如何帮助你排队：

export default function* watchRequests() {
  while (true) {
    // 1- Create a channel for request actions
    const requestChan = yield actionChannel('ASYNC_ACTION');
    let resetChannel = false;

    while (!resetChannel) {
      // 2- take from the channel
      const action = yield take(requestChan);
      // 3- Note that we're using a blocking call
      resetChannel = yield call(handleRequest, action);
    }
  }
}

function* handleRequest({ asyncAction, payload }) {
  while (true) {
    try {
      // Perform action
      yield call(asyncAction, payload);
      return false;
    } catch(e) {

      if(e instanceof ConflictError) {
        // Could be a rollback or syncing again with server?
        yield put({ type: 'ROLLBACK', payload });
        // Store is out of consistency so
        // don't let waiting actions come through
        return true;
      } else if(e instanceof ConnectionError) {
        // try again
        yield call(delay, 2000);
      }

    }
  }
}

因此，这里有趣的部分是通道如何充当缓冲区（队列），它保持“监听”传入的操作，但在完成当前操作之前不会继续执行将来的操作。您可能需要查看他们的文档以便更好地掌握代码，但我认为这是值得的。重置渠道部分可能或不适合您的需求：思考：

希望它有所帮助！

相关问题
最新问题