javascript - 如何正确处理双嵌套数组(ReactJS + Redux)中的状态？

Question

我正在尝试构建以下内容:一个可以创建帖子的论坛，这会触发 ADD_POST，然后创建帖子并将其添加到“帖子”对象数组中。每个“帖子”对象都使用一个“评论”数组进行初始化，该数组将保存在该帖子中输入的评论文本(“commentTxt”)。

let postReducer = function(posts = [],  action) {
  switch (action.type) {
    case 'ADD_POST':
      return [{
        id: getId(posts), //just calls a function that provides an id that increments by 1 starting from 0
        comments: [
          {
            id: getId(posts),
            commentTxt: ''
          }
        ]
      }, ...posts]

然后当用户输入该帖子时，会有一个评论部分，用户可以在其中输入评论文本，并且一个新对象将被添加(通过“ADD_COMMENT”)到“posts.comments”数组中

  case 'ADD_COMMENT':
      return posts.map(function(post){
    //find the right 'post' object in the 'posts' array to update the correct 'comments' array. 
        if(post.id === action.id){
    //update 'comments' object array of a 'post' object by adding a new object that contains 'commentTxt', and replaces the current 'comments' array
          return post.comments = [{
            id: action.id,
    //new object is made with text entered (action.commentTxt) and added to 'post.comments' array
            commentTxt: action.commentTxt
          }, ...post.comments]
        }
      })

并会显示它。并且每次添加新评论时，新评论将与数组中的先前评论对象一起呈现。想要执行以下操作:

      {
        this.props.post.comments.map((comment) => {
          return <Comment key={comment.id} comment={comment} actions={this.props.actions}/>
        })
      }

我听说不建议直接改变状态，所以我很感激任何关于如何正确地这样做的指导或见解。

Answer 1

您可能会考虑规范化您的数据。所以，不要像这样存储你的结构:

posts: [{
  title: 'Some post',
  comments: [{
    text: 'Hey there'
  }]
}]

你会像这样存储它们:

posts: [{
  id: 1,
  title: 'Some post'
}]

comments: [{
  id: 4,
  postId: 1,
  text: 'Hey there'
}]

一开始会比较痛苦，但可以提供很大的灵 active 。

或者，您可以修改 ADD_COMMENT reducer:

return posts.map(function(post) { 
  if (post.id !== action.id) {
    return post
  }


  return {
    ...post, 
    comments: [
      ...post.comments, 
      { 
        id: action.id, 
        commentTxt: action.commentTxt 
      }
    ]
  }
}

注意:在最后一个解决方案中，没有突变。不知道它会如何处理大量评论，但除非你有充分的理由，否则我不会针对这种情况进行预优化。