Skip to content

Conversation

@pkarw
Copy link
Collaborator

@pkarw pkarw commented Sep 27, 2018

Related issues

#1713, #1688

Short description and why it's useful

I've changed the way SSR pages are generated:

  • now distinct routes can set "context.serverOutputTemplate" in asyncData and by doing so You can skip using dist/index.html (which contains typical HTML5 elements - like <head ...). This is important when we're going to generate AMPHTML pages (that can not contain any <script> tags) - either xml files - You name it
  • distinct routes can set meta.layout and by doing so switch the previously constant App.vue layout file - this is what @mercs600 proposed some time ago in slightly changed form

Upgrade Notes and Changelog

The themes/default/index.template.html and src/index.template.html template files have been modified by adding renderStyles(), renderState() helpers. AFAIK nobody is modifying these templates - but if sbd. did - he/she must change it accordingly otherwise styles won't be rendered properly

  • No upgrade steps required (100% backward compatibility)
  • I've updated the Upgrade notes and Changelog on how to port existing VS sites with this new feature

Contribution and curently important rules acceptance

export default {
name: 'RawOutputExample',
asyncData ({ store, route, context }) {
context.response.setHeader('Content-Type', 'text/xml')
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here You can now set from the Vue component level server response headers + choose template

import RawOutputExample from './pages/RawOutputExample.vue'

export default [
{ path: '/raw-output-example.xml', component: RawOutputExample, serverOutputTemplate: '', meta: { layout: 'empty' } }
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can now also set the layout from the routes level

@filrak
Copy link
Collaborator

filrak commented Sep 28, 2018

// removed unecessary
And how this will work with @vue/ssr-plugin that we will use in our boilerplate?

AAnd of course - shouldn't this features be a separate modules? now we are adding new functionalities that may not be useful for some people. It'll also help to encapsulate the behavior

@filrak
Copy link
Collaborator

filrak commented Sep 28, 2018

Also, can we add posibility to server side render onlyc ertain pages (i know it's not connected but still alout SSR, there was an issue for this). This would prevent a lot of SSR errors that we have right now in pages that just don't need to use it.

@pkarw
Copy link
Collaborator Author

pkarw commented Sep 28, 2018

We can theoretically filter the urls from SSR routing - however I don’t see many use cases for that. How wupuld you like to use it?

@filrak
Copy link
Collaborator

filrak commented Sep 28, 2018

We can theoretically filter the urls from SSR routing - however I don’t see many use cases for that. How wupuld you like to use it?

We discussed it earlier. For SEO ssr is useful only for homepage and catalog. By disabling ti on unnecesary pages people will be able to use client-side libs without any problems which will be a huge benefit in dev experience

new CaseSensitivePathsPlugin(),
new VueLoaderPlugin()
new VueLoaderPlugin(),
// generate output HTML
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe this files should be provided in config or exported from some place that develoeprs can reach (not from core)?

@vuestorefront vuestorefront deleted a comment from pkarw Sep 28, 2018
@pkarw pkarw merged commit b53287e into vuestorefront:develop Oct 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants