Vue에서 $destroy 성능 향상

소개

대부분의 경우 Vue는 충분히 빠른 프레임워크입니다. 그러나 노드 파괴 시간은 매우 길 수 있습니다. 물론 DOM에서 요소를 제거하는 것은 빠른 작업이지만 Vue는 소멸 구성 요소에서 모든 감시자를 제거해야 하며 몇 초가 걸릴 수 있습니다.

사례

12개의 그룹이 있는 중첩된 탐색이 있는 구성 요소에는 각각 ~20개의 하위 항목이 있습니다. 모든 그룹을 연 후 탐색에는 최대 240개의 항목이 있습니다. 사용자가 다른 보기 브라우저로 이동하려고 하면 몇 초 동안 정지됩니다.

Navigation
 - Group x12
   - Item x20

조사

크롬 개발 도구를 열고 성능 섹션으로 이동하여 CPU: 4배 느리게 설정하면 해당 브라우저가 일반 사용자 컴퓨터에서처럼 작동합니다.



그런 다음 내비게이션 파괴를 기록하십시오. 결과:



맙소사 거의 7초의 파괴와 0.65초의 업데이트(파괴 전) o.O



기본$destroy에는 더 짧은 $destroy가 많이 있으며 모두 removeSub 호출이 많습니다. 각각의 removeSub는 7~15ms가 걸리지만 전체적으로는 브라우저 정지 시간이 많습니다.

이유

구성 요소Item.vue는 5개의 상위 vuex getter에 바인딩되어 약 240번 렌더링되었습니다.

// Item.vue
...mapGetters('namespace', [
  'getA',
  'getB',
  'getC',
  'getD',
  'getE',
});

또한 Item.vue에는 8개의 계산 속성이 있으며 그 중 5개는 vuex getter를 사용합니다. 이 모든 작업은 비용이 많이 들지 않지만 많은 구독을 생성합니다. 그리고 이러한 구독은 삭제되어야 합니다.

해결책

계산된 모든 props 및 vuex 바인딩을 Item.vue에서 Group.vue로 이동합니다. Group.vue는 많은 Item.vue를 렌더링하므로 다음과 같이 항목 컬렉션을 매핑해야 합니다.

결과

$destroy의 시간이 ~7초에서 0.3초로 감소했습니다(-96%). 또한 0.65초에서 0.45초(-30%)로 감소하기 전에 업데이트하십시오. 이것은 완벽한 해결책이 아닙니다. 매퍼가 Navigation.vue로 이동해야 하므로 패스Group.vue를 소품으로 추가해야 합니다. 그러나 a, b, c, d, e의 이동 계산은 바인딩을 55(12 * 5 - 5)로 "만"줄입니다. 이 성능은 훌륭하지는 않지만 끔찍하지는 않습니다.

결론

vue에서 스토어에서 컴포넌트로 데이터를 로드하는 것은 매우 쉽습니다. 단지 ...mapGetters('namespace', ['getter']) 이지만 모든 컴포넌트가 스토어에 대해 알아야 하는 것은 아닙니다. 이전에는 React의 후크가 mapStateToProps 및 mapDispatchToPros에 의해 Redux의 데이터를 구성 요소와 연결하는 컨테이너를 작성하는 데 매우 인기가 있었습니다. 그것은 많은 상용구였고 우리가 지금 사용할 수 있다는 점에 감사합니다useReducer. 하지만 한 가지 장점이 있습니다. 제 생각에는 구성 요소를 로직과 프리젠테이션으로 분리하는 것이 코드를 깔끔하게 유지하는 것뿐만 아니라 성능 목적을 위해서도 중요하기 때문에 여전히 신경써야 합니다.