Introduction
Vue in most of the cases is a fast enough framework. However, the time of nodes destruction can be very long. Of course removing elements from DOM is fast operation but Vue needs to remove all watchers from destruct component and that may take up to several seconds.
Case
Component with nested navigation with 12 groups each has ~20 children. After opening all groups, navigation has ~240 items. After user tries to navigate to another view browser freezes for a couple of seconds.
Navigation
- Group x12
- Item x20
Investigation
Open chromium dev tools, go to the performance section and set CPU: 4x slower after that browser will behave as on an average user computer.
Then record the destruction of navigation. The result:
Oh my God almost 7 seconds of destroy and 0.65 s of update (before destroy) o.O
In the main $destroy
there’s many shorter $destroys and all of them have many removeSub calls. Each of removeSub
takes 7–15 ms, not much but in total it’s much time of browser freeze.
Reason
Component Item.vue
is bind to 5 high order vuex getters was rendered around 240 times.
// Item.vue
...mapGetters('namespace', [
'getA',
'getB',
'getC',
'getD',
'getE',
});
Also Item.vue
has 8 computed properties and 5 of them use vuex getters. All this operations are not expensive, however create many subscriptions. And these subscriptions have to be cleared.
Solution
Moving all computed props and vuex bindings from Item.vue
into Group.vue
. Group.vue
is rendering many Item.vue
s so we have to map collection of item like this:
Result
Time of $destroy
reduced from ~7s to 0.3s (-96%). Also update before it wad reduced from 0.65s to 0.45 (-30%). Notice that is not a perfect solution: because mapper should move to Navigation.vue
add pass Group.vue
as prop. However moving calculation of a, b, c, d, e will “only” reduced bindings by 55 (12 * 5 – 5). This performance is not great but not terrible.
Conclusion
In vue loading data from store to component is pretty easy: just ...mapGetters('namespace', ['getter'])
, but not all components should know about the store. Before React’s hooks was very popular to write container that connect data from Redux by mapStateToProps
and mapDispatchToPros
with a component. It was a lot of boilerplate and thank goodness we can use now useReducer
however it has one advantage: get the developer to think about where to put the connection with store. In my opinion we still must care about it because separation of components into logic and presentation is important not only to keep code clean but also for performance purposes.
Top comments (0)