Vue in most of the cases is a fast enough framework. However, the time to destroy nodes can be very long. Of course removing elements from DOM is fast operation but vue needs to remove all watchers from the destruct component and that may take up to several seconds.
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 frees for a couple seconds.
- Group x12
- Item x20
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.
Item.vue is bind to 5 high order vuex getters was rendered around 240 times.
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.
Moving all computed props and vuex bindings from
Group.vue is rendering many
Item.vues so we have to map collection of item like this:
Group.vue doesn’t need these attributes but we want to reduce the amount of things to unsubscribe.
$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.
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
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 not only to keep code clean but also for performance purposes.