Global API Treeshaking

[yyx990803]

Rendered

[laander]

Would this also apply to more core concepts such as Vue.extend?

Instead of:

import Vue from 'vue'

Vue.extend({
  ...
})

We would do:

import { extend } from 'vue'

extend({
  ...
})

[yyx990803]

@laander extend is probably going to be an exception and kept on Vue itself. The code for internal class extension is going to be included in any app anyway.

[phanan]

Note the above only applies to the ES Modules builds for use with tree-shaking capable bundlers - the UMD build still includes all features and exposes everything on the Vue global variable (and the compiler will produce appropriate output to use APIs off the global instead of importing).

When it all makes sense, I'm a bit concerned when it comes to documentation. How would we present both modules and UMD APIs in our examples? Off the top of my head, we can:

1. Use a tabbed interface for the examples, with each tab using the corresponding API/syntax, or
2. Only use one of the two for the examples, with the other documented somewhere

IMHO 1 is better, but I'm not sure about the maintenance method and whether it can be automated.

[laander]

@yyx990803 I assume that everything that registers on/interacts with the global Vue instance can't be extracted, right? E.g.
Vue.directive
Vue.filter
Vue.component
Vue.mixin
Vue.use

[yyx990803]

@laander these are APIs that globally mutate the Vue constructor and will likely be re-designed (which will have its own RFC).

[clemyan]

Naming the function that creates VNodes as h is (as far as I can see) a legacy of Vue 2.x, where it is passed as an argument to the render function and the consumer can choose any variable name for it.

With ES modules, we can export the function under any name while the importer is still free to rename it anything. So, IMO, we should export it under a more descriptive name like createVNode and encourage the convention import { createVNode as h } from 'vue'.

This would be invisible to users writing templates or JSX (since the import statement is generated by the compiler anyway) and communicate more clearly to render function writer what the function is doing.

[yyx990803]

@clemyan I like that. See fb11b66 (note createVNode is in fact something lower-level that exists internally, the public one should be createElement to be precise)

[agronick]

I'm in favor of exporting as much as possible. The other day I was trying to import supportsPassive and found that it couldn't be done. The only way to find out if the browser supported passive event handlers was to duplicate the same logic already built into Vue.

[onx2]

If a codebase only uses the Composition API, is the Options API something that is tree-shaken?

[yyx990803]

@onx2 by default it cannot, because we cannot predict what options the users will use. But there will be a compile-time flag to drop it.