Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server-side: Function type prop’s default function is undefined when rendering server-side #4872

Closed
shentao opened this issue Feb 6, 2017 · 2 comments
Labels

Comments

@shentao
Copy link
Member

shentao commented Feb 6, 2017

Vue.js version

2.1.10

Reproduction Link

https://github.com/shentao/vue-hackernews-2.0

Steps to reproduce

  1. Run the app
npm run dev

What is Expected?

<my-comp></my-comp> should render to <div>Default function result: value</div>

What is actually happening?

<my-comp></my-comp> throws error:

Vue warn]: Invalid prop: type check failed for prop "functionProp". Expected Function, got String. 
(found in component <my-comp> at /Users/damiandulisz/code/private/vue-hackernews-2.0/src/MyComp.vue)
Default function result: undefined
[Vue warn]: Error when rendering component <my-comp> at /Users/damiandulisz/code/private/vue-hackernews-2.0/src/MyComp.vue: 
error during render : /top
TypeError: _vm.functionProp is not a function
    at Proxy.render (__vue_ssr_bundle__:1605:48)
    at VueComponent.Vue._render (/Users/damiandulisz/code/private/vue-hackernews-2.0/node_modules/vue/dist/vue.runtime.common.js:2216:22)
    at renderComponent (/Users/damiandulisz/code/private/vue-hackernews-2.0/node_modules/vue-server-renderer/build.js:6078:25)
    at renderNode (/Users/damiandulisz/code/private/vue-hackernews-2.0/node_modules/vue-server-renderer/build.js:6061:7)
    at next (/Users/damiandulisz/code/private/vue-hackernews-2.0/node_modules/vue-server-renderer/build.js:6197:9)
    at next (/Users/damiandulisz/code/private/vue-hackernews-2.0/node_modules/vue-server-renderer/build.js:6189:7)
    at Object.cachedWrite [as write] (/Users/damiandulisz/code/private/vue-hackernews-2.0/node_modules/vue-server-renderer/build.js:36:9)
    at next (/Users/damiandulisz/code/private/vue-hackernews-2.0/node_modules/vue-server-renderer/build.js:6199:17)
    at cachedWrite (/Users/damiandulisz/code/private/vue-hackernews-2.0/node_modules/vue-server-renderer/build.js:36:9)
    at renderNode (/Users/damiandulisz/code/private/vue-hackernews-2.0/node_modules/vue-server-renderer/build.js:6069:7)
@HerringtonDarkholme
Copy link
Member

HerringtonDarkholme commented Feb 7, 2017

I cannot reproduce it in jsfiddle. https://jsfiddle.net/ko6pwtLu/

Is this ssr only issue?

Edit: Reproducible on server. Seems a ssr only issue.

@HerringtonDarkholme
Copy link
Member

HerringtonDarkholme commented Feb 8, 2017

Ah, the problem is how we render server bundle. Vue-SSR will render bundle in a new context, so two Function constant is different.

Update: Function identity is exactly the problem. I have not come up with a good approach to determine whether an object is Function constructor. The solution must be context independent and parsimoniously performant since getPropDefaultValue may be called in component instantiation.

We may pack Vue into the server bundle so that Function in user code and library code refers to the same object. But it might bring significant overhead to SSR because vm.runInContext will compile script every time. (I don't have enough knowledge in nodejs internal, correct me if anything wrong).

Other library code may also encounter such problem in SSR. Components, if they are not bundled into server entry, cannot compare any builtin object to user provided value.

@yyx990803 what's your opinion?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants