You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
v-once and v-memo are mentioned as options for improving performance on this page. The documentation for v-memo says:
v-memo is provided solely for micro optimizations in performance-critical scenarios and should be rarely needed. The most common case where this may prove helpful is when rendering large v-for lists (where length > 1000)
The submissions table seems like a good example of that case.
That said, I've already reduced the reactivity of the submission requestData. That means that the submission row components already have very few reactive dependencies. If there is limited reactivity already, would v-once and v-memo have any additional benefit? My guess is yes, because even if the submission requestData is minimally reactive, the component props are still reactive: the submission row components don't know that they're used within a context that guarantees that their props are immutable.
The text was updated successfully, but these errors were encountered:
v-once
andv-memo
are mentioned as options for improving performance on this page. The documentation forv-memo
says:The submissions table seems like a good example of that case.
That said, I've already reduced the reactivity of the submission
requestData
. That means that the submission row components already have very few reactive dependencies. If there is limited reactivity already, wouldv-once
andv-memo
have any additional benefit? My guess is yes, because even if the submissionrequestData
is minimally reactive, the component props are still reactive: the submission row components don't know that they're used within a context that guarantees that their props are immutable.The text was updated successfully, but these errors were encountered: