[holtalanm]

> In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application.

Implemented a undo/redo stack on top of Vuex once that worked on some very large data structures.

Got unresponsiveness after only ~3 changes to the data. Purely due to how Vuex checks state for changes. No network, no database; purely in the frontend client.

Ended up needing to freeze the state as I pushed it into the Vuex store, so Vuex wouldn't check previously pushed state for changes.

My point is, there are multiple places where, if you are building an app of scale, you can run into client performance issues.

[dstick]

Would you mind elaborating a bit on _how_ you implemented this? In my experience with Vuex and large datasets with dozens of stores, the devil is in the detail and how you change stuff matters a lot.

For example, you can't just create and keep a copy of a dataset / variable. It will remain reactive. You need to clone it. Failing to do so will indeed quickly clog up... everything :D

[holtalanm]

you don't have to clone it. cloning the object and putting it in Vuex will still result in it being reactive.

`Object.freeze` is what I used. This causes Vuex to not traverse the object for changes. in my case, the objects I was pushing into the Vuex state were essentially immutable once I pushed them in, so this did the ticket.

well, that, and only pushing partials of the entire state, so the object model didn't get too unwieldy. To get the total state, i just replayed the changes on top of the base state. base state was reset once the number of changes got to a certain size.