redux导致40＆＃x2b;单页上的重新租户：想要帮助识别/修复问题

Question

我正在为音乐理论应用程序公司的仪表板网站工作，用户可以在该网站上管理其信息，课程，作业，媒体内容等。

该网站是使用React Hooks和Redux Toolkit构建的。我正在处理的当前页面是教师用户编辑作业集（分配详细信息和与该分配相关的任何练习）。我们希望用户能够通过键入来导航到每个分配编辑页面，因此URL类似于course/{CourseID}/sigsmenment/aissignment/{sigsionmentId}。这意味着任何时候加载此页面，我需要进行API调用以获取我需要的任何后端数据。

我的整体Redux商店对象非常简单。这是与我在有关页面上抓取的内容有关的示例：

store: {
  singleCourse: {
    courseInfo: <courseInfoObj>,
    students: [...<studentsObjs>],
    assignments: [...<assignmentObjs>],
  },
  singleAssignment: {
    assignmentInfo: <assignmentInfoObj>,
    exercises: [...<exerciseObjs>],
  },
  contentLibrary: {
    library: [...<libraryObjs>]
  }
}

页面是构造的，因此我有一个useffect使用batch将所有派遣我需要采取的操作。然后，我用use -elector从Redux Store中获取所需的东西。在此页面上，我需要dispatch 6个不同的操作（到6个不同的API路由）才能获取我需要的所有数据，该数据存储在上面列出的3个还原器上。要从Redux获取数据，我正在执行const {singleCourse，singleSignment，contentLibrary} = useselector（state =＆gt; state）

我注意到该页面的重新呈现高达40+时间（在作业中列出的练习越多，重新汇款越多）。在我的调试中，我注意到，当我删除任何use-elector呼叫时，重新租赁的数量会大大下降。请注意，我正在通过在我的功能页面之前定义的数字变量来跟踪渲染器，并在我的JSX返回之前将其递增/记录。

使用Esselector从Redux商店中抓住东西可以成为这种疯狂的重新租赁数量的原因吗？我已经做了一些有关使用记忆的选择器来防止重新渲染过多的研究（并且我可以使用Redux Toolkit中使用CreateSelector），但是这些示例与我的案例完全无关。我的生活我不知道如何在我的情况下使用它。

另外，在此特定页面上，我派遣6个不同的动作来更新3个单独的还原器是不好的做法吗？

这些页面的加载很快并且反应迅速，但是我担心所有这些重新汇款都会/会引起重大问题。

谢谢

编辑：这是更多代码供参考。

sizhtmentDetailpage.tsx

const AssignmentDetailPage = () => {
  const { courseID, assignmentID } = useParams();

// dispatches

  useEffect(() => {
    batch(() => {
      
      dispatch(getCourseDetail(courseID));
      dispatch(getCourseStudents(courseID));
      dispatch(getCourseAssignments(courseID));
      dispatch(getAssignmentAndDocuments(assignmentID));
      dispatch(listAssignmentDueDateExtensions(assignmentID));
      dispatch(getEntireContentLibrary());
    })
  }, [dispatch]);



  // Grabbing  from Redux store.



  const selectedCourse = useHarmoniaSelector(state=> state.selectedCourse);
  const selectedAssignment = useHarmoniaSelector(state => state.selectedAssignment);
  const contentLibrary = useHarmoniaSelector(state => state.contentLibrary);


  // Grabbing assignment info from assignments state.

  const assignment = selectedAssignment.assignment as Assignment || {};

  const dueDateExtensions = selectedAssignment.dueDateExtensions as DueDateExtension[];


  const documents = selectedAssignment.documents || [] as Document[];


  // Grabbing array of assignments and finding assignmentIndex of current assignment.
  const courseAssignments = selectedCourse.assignments as Assignment[] || [];

  const courseStudents = selectedCourse.students || [] as CourseStudent[];

}

这是一个带有selectedAssignment的redux东西的示例：

selectedAssignment.ts

type SelectedAssignmentInitialState = {
  assignment?: Assignment | null,
  documents?: Document[] | null,
  dueDateExtensions?: DueDateExtension[] | null
}
const initialState: SelectedAssignmentInitialState = {};

// actions
export const getAssignmentAndDocuments = createAsyncThunk
<Assignment, number, {rejectValue: void}>
('assignments/getAssignmentDetail', async(assignmentID, {dispatch, rejectWithValue}) => {
  try{
    const response = await API.get(`/api/assignments/${assignmentID}`);
    return response.data.data as Assignment;
  }catch(e){
    dispatch(pushErrorNotification(errorMessage(e.data)));
    return rejectWithValue();
  }
});

export const listAssignmentDueDateExtensions = createAsyncThunk<DueDateExtension[], number, {rejectValue: void}  >('assignment/listAssignmentDueDateExtensions', async (assignmentID, {dispatch, rejectWithValue}) => {
  try{
    const response = await API.get(`/api/assignments/${assignmentID}/due-day-extensions`);
    return response.data.data as DueDateExtension[];
  }catch(e){
    dispatch(pushErrorNotification(e.data));
    return rejectWithValue();
  }
});

// reducer

const selectedAssignmentSlice = createSlice({
  name: 'selectedAssignment',
  initialState,
  reducers: {},
  extraReducers: (builder) => {
    builder
    .addCase(
      getAssignmentAndDocuments.fulfilled,
      ((state, {payload}) => {
        // assignmentDetail is everything but documents; documents kept on separate key in state obj to keep things simpler.
        const {course, documents, due_at, id, released_at, set_key, show_after_due, title, weight} = payload;
        state.assignment = {course, due_at, id, released_at, set_key, show_after_due, title, weight};
        state.documents = documents;
      })
      )
.addCase(listAssignmentDueDateExtensions.fulfilled, ((state, {payload}) => {
        state.dueDateExtensions = payload;
      }))

Answer 1

您将要介绍该应用程序以找到您的真正瓶颈。不鼓励编写完美的缓存代码并记住所有内容，因为这是影响开发人员生产力可维护性/错误等的过早优化。

随着这些功能，尽最大努力尽力而为。

这是关于在状态下放置的内容的好阅读，并尝试将“派生数据”（如计算）遗漏。 https://redux.js.org/usage/usage/deriving-data-selectors

这是关于使用elector有效的很好的阅读：
https：//react-react-react-react-react-react-reac.js.s.org/api/hooks#performance

我要樱桃选择一些我认为适用的东西：

使用Elector在每个动作后运行。如果返回的响应与最后结果的参考比较有所不同，则将迫使组件重新渲染。

您的使用elector呼叫正在返回状态对象。状态对象将因每个动作的参考平等而有所不同，因此它将始终迫使重新渲染。

制作一个返回状态树中每个项目的选择器。假设您不是创建新对象，除非状态的那一部分发生变化，否则这些选择器不会默认情况下引起重新租户。

例如，浸入/redux工具包将保留不变的状态树部分。您也应该尝试使用标准REDUX，例如返回旧状态，除非还原器在该状态下行动。

那可能是最大的。您应该准确调查是什么原因导致了重新租赁的原因，在基本使用者优化（不要返回整个状态树），然后开始寻找适当的解决方案。

另外，在此特定页面上，我派遣6个不同的动作来更新3个单独的还原器？

是不好的做法吗？

我认为这不好。那不是很多。一个Redux工具包异步动作将发射3个动作。

页面的加载很快并且反应迅速，但是我担心所有这些重新租户都会/会引起重大问题。

是的，我认为您需要肯定要注意，但请再次谨慎对待过早优化。我会试图确保没有犯重大错误（例如不依靠使用默认参考检查），但除此之外，没有更多的优化。为经过验证的瓶颈留出代码复杂性的空间。