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

[SSR] Rendering of Components with inline string template crashes #879

Closed
ma-jahn opened this issue Dec 9, 2019 · 9 comments
Closed

[SSR] Rendering of Components with inline string template crashes #879

ma-jahn opened this issue Dec 9, 2019 · 9 comments
Labels

Comments

@ma-jahn
Copy link

ma-jahn commented Dec 9, 2019

Describe the bug
After upgrading from 3.0.0 to 3.0.2 i found that the rendering of our dynamic components is broken. It looks like it was caused by a change in 3.0.1 (#852).
If a component doesn't have an explicit render function, it will brake when executing render.call (mixin.js line 156).
This bug was also mentioned by @drewbaker here: e6cbaa2

To Reproduce
Create a view with a dynamic component

<template>
  <TemplateLiteralComponent/>
</template>

<script>
export default {
  name: 'BugReport',
  components: {
    TemplateLiteralComponent,
  },
  apollo: {
    something: {
       query: someQuery.gql,
    }
  },
}
</script>

And use a component that doesn't have a render function

<script>
export default {
  name: 'TemplateLiteralComponent',
  template: '<h3>TemplateLiteralComponent</h3>',
}
</script>

Expected behavior
This should render Test inside a div.cms-content.

Versions
vue: 2.6.10
vue-apollo: 3.0.2

@LinusBorg
Copy link
Member

LinusBorg commented Dec 9, 2019

Your computed property is weird, it registers a global component (which is a side-effect that computed properties should not do), and doesn't return anything, so it will always evaluate to false

If that's the code you actually use, I don't see how it could have ever worked, and I don't see how this is related to vue-apollo.

Assuming your example is incorrect/incomplete, please correct it.

@ma-jahn
Copy link
Author

ma-jahn commented Dec 9, 2019

Thanks for pointing out the side-effect. I'll work on that.

I've changed the example above to only use a single static component with a template string.

@drewbaker
Copy link

This component throws that error for me: https://github.com/funkhaus/haus-components/blob/master/WpContent.vue

Downgrading works.

FYI that component Is special in that it allows a string of HTML from WordPress to be passed in, and that string can have Vue components in it and those will be rendered. It requires the compiler version of Vue.

@rchl
Copy link

rchl commented Dec 10, 2019

My services are broken after upgrading @nuxtjs/apollo (which upgraded vue-apollo from v3.0.0 to v3.0.1):

TypeError
Cannot read property 'call' of undefined

Screenshot 2019-12-10 at 16 00 21

@rchl
Copy link

rchl commented Dec 10, 2019

The pages that are broken are using v-runtime-template/vue-template-compile which might be related.

@PayteR
Copy link

PayteR commented Dec 21, 2019

Same error here on nuxt, broken after update 3.0.0 > 3.0.1 here is sandbox

https://codesandbox.io/s/wp-content-urj01?fontsize=14&hidenavigation=1&theme=dark

problem is same with render function, that is located components/WpTest.vue

@rchl
Copy link

rchl commented Jan 24, 2020

This is a serious regression, probably not only for Nuxt users.

@LinusBorg
Copy link
Member

@Akryum I think this needs some attention, do you have a bit of time to check this out?

Seems to be pretty straighforward to fix but I don't feel confident in this codebase to send a PR

@Akryum
Copy link
Member

Akryum commented Jan 24, 2020

Will look at it today.

@Akryum Akryum changed the title Rendering of Components without render function broken Rendering of Components with inline string template crashes Jan 24, 2020
@Akryum Akryum changed the title Rendering of Components with inline string template crashes [SSR] Rendering of Components with inline string template crashes Jan 24, 2020
@Akryum Akryum added bug and removed pending triage labels Jan 24, 2020
@Akryum Akryum closed this as completed in 0051c43 Jan 24, 2020
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

6 participants