refactor(reactivity): reduce size of collectionHandlers

[skirtles-code]

The diff looks horrendous... the change really isn't that complicated.

Bundle size

My primary goal was to reduce the bundle size. I've removed a lot of redundancy from collectionHandlers.ts. That involved moving around a lot of code, but it essentially all still works the same way.

To make this a bit easier to review I've split it up into individual commits. The first commit is the key change to understand what I've done. createInstrumentations was previously creating 4 lots of instrumentations and then returning them. The new version just creates the instrumentations for a single case, based on the arguments readonly and shallow. Just that one change reduces the bundle size by about 566 bytes, or roughly 135 bytes after gzipping.

The other commits gradually inline each of the functions. I checked after each commit to ensure that they really did reduce the bundle size further.

The final result is about 220 bytes saved after gzipping. In the Usages size checks that's a saving of about 1%.

Fixes minor bugs

A key part of the new approach is that readonly and shallow are arguments passed to createInstrumentations, which are then caught in the closure of the specific handlers. Previously these argument were passed directly to the handlers.

The old approach could lead to minor bugs in edge cases, due to the ghost parameters:

• Playground example - 3.5.11

The reason for the inconsistency in this example is that the add method takes _isShallow as its second argument. This is only supposed to be passed internally, but it also gets passed automatically by forEach in the example above.

With the refactoring in this PR, those ghost parameters are removed, so these kinds of inconsistencies should no longer occur:

• Playground example - this PR

Performance

I don't think this PR should have a significant impact on performance. Inlining the handlers may have slightly improved performance in some cases, as it removes an extra function call.

For example, this Playground gives slightly quicker times for me when testing in Chrome:

• Playground - 3.5.11
• Playground - this PR

Impact on other PRs

Such a large amount of churn, albeit within a single file, is a cause for concern. I've checked how this would impact existing PRs.

These PRs would conflict with this PR:

• fix(reactivity): not trigger Map.size when setting existing keys #7328 - This change looks good to me and can probably be merged. The conflict should be trivial to resolve, whichever PR gets merged first.
• refactor(reactivity): instrumentation handling for specific cases #9141 - I think only the imports would conflict, so trivially resolved.
• feat: the reactive set supports the difference, intersection, isDisjointFrom, isSubsetOf, isSupersetOf, and symmetricDifference methods #11399 - The conflicts should be easily fixable. If anything, the changes here will simplify that PR, as it currently repeats much of the code.

These PRs make changes to collectionHandler.ts, but I don't think this PR would cause any conflicts:

• fix(types): reactive collection type is not as expected (#5954) #6350
• fix(reactivity): toRaw on object using reactive as prototype (#6268) #6355

[github-actions]

Size Report

Bundles

File	Size	Gzip	Brotli
runtime-dom.global.prod.js	100 kB (-807 B)	37.9 kB (-210 B)	34.1 kB (-152 B)
vue.global.prod.js	159 kB (-807 B)	57.9 kB (-204 B)	51.5 kB (-156 B)

Usages

Name	Size	Gzip	Brotli
createApp (CAPI only)	48.4 kB (-807 B)	18.8 kB (-235 B)	17.1 kB (-194 B)
createApp	55 kB (-807 B)	21.3 kB (-215 B)	19.4 kB (-177 B)
createSSRApp	59 kB (-807 B)	23 kB (-234 B)	20.9 kB (-187 B)
defineCustomElement	59.8 kB (-807 B)	22.8 kB (-216 B)	20.8 kB (-172 B)
overall	68.7 kB (-807 B)	26.3 kB (-222 B)	24 kB (-199 B)

[pkg-pr-new]

Open in Stackblitz

@vue/compiler-core

pnpm add https://pkg.pr.new/@vue/compiler-core@12152

@vue/compiler-dom

pnpm add https://pkg.pr.new/@vue/compiler-dom@12152

@vue/compiler-sfc

pnpm add https://pkg.pr.new/@vue/compiler-sfc@12152

@vue/reactivity

pnpm add https://pkg.pr.new/@vue/reactivity@12152

@vue/compiler-ssr

pnpm add https://pkg.pr.new/@vue/compiler-ssr@12152

@vue/runtime-core

pnpm add https://pkg.pr.new/@vue/runtime-core@12152

@vue/runtime-dom

pnpm add https://pkg.pr.new/@vue/runtime-dom@12152

@vue/server-renderer

pnpm add https://pkg.pr.new/@vue/server-renderer@12152

@vue/shared

pnpm add https://pkg.pr.new/@vue/shared@12152

@vue/compat

pnpm add https://pkg.pr.new/@vue/compat@12152

vue

pnpm add https://pkg.pr.new/vue@12152

commit: f08f58e

[Justineo]

/ecosystem-ci run

[vue-bot]

📝 Ran ecosystem CI: Open

suite	result	latest scheduled
language-tools	❌ failure	❌ failure
nuxt	✅ success	✅ success
pinia	✅ success	✅ success
primevue	✅ success	✅ success
quasar	✅ success	✅ success
radix-vue	✅ success	✅ success
router	✅ success	✅ success
test-utils	✅ success	✅ success
vant	✅ success	✅ success
vite-plugin-vue	✅ success	✅ success
vitepress	✅ success	✅ success
vue-i18n	✅ success	✅ success
vue-macros	✅ success	✅ success
vuetify	✅ success	✅ success
vueuse	✅ success	✅ success
vue-simple-compiler	✅ success	✅ success

[caendesilva]

Flawless PR description! Great job Skirtles!

[zhangenming]

"I've checked how this would impact existing PRs."

What method did you use to accomplish this?

[skirtles-code]

"I've checked how this would impact existing PRs."

What method did you use to accomplish this?

I have some scripts at https://github.com/skirtles-code/github-analysis-scripts that I used to download the open PRs. Once I had the changes locally I just searched for changes to collectionHandlers.ts.