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

vue-server-renderer: camelCased local directives are not applied in SSR #8961

Closed
TheAlexLichter opened this issue Oct 16, 2018 · 8 comments
Closed
Labels

Comments

@TheAlexLichter
Copy link
Contributor

TheAlexLichter commented Oct 16, 2018

What problem does this feature solve?

Currently, SSR directives can be only passed in with 'kebab-case' keys. This isn't denoted anywhere (except in the tests, luckily!) and not "intuitive" as they can be provided as camelCased ones on the client as well.

Can we introduce camelCased SSR directives?
I'd be available to work on the impl.

What does the proposed API look like?

directives: {
  classPrefixer: (node, dir) => {/*...*/}
}
@TheAlexLichter TheAlexLichter changed the title Allow camelCased SSR directives vue-server-renderer: Allow camelCased SSR directives Oct 16, 2018
@posva
Copy link
Member

posva commented Oct 17, 2018

Can you provide a code sample that doesn't work? Directives are always in kebab-case, event on client

@TheAlexLichter
Copy link
Contributor Author

Hey @posva! 👋

You can pass them in as camelCase variants as well on client side (repro: https://codesandbox.io/s/yv37k52vyv). That's why I assumed it's possible for the vue-server-renderer as well 🙈

@posva
Copy link
Member

posva commented Oct 17, 2018

But can you provide the simple js file that fails when ran with node? That should work

@TheAlexLichter
Copy link
Contributor Author

@posva Sure! There you go: https://codesandbox.io/s/w0vjky43l5

The directive is passed directly to the createBundleRenderer fn in Nuxt (https://github.com/nuxt/nuxt.js/blob/d35fc8f01584c3566d96cd1844413bca177a54a7/lib/core/renderer.js#L158)

@posva
Copy link
Member

posva commented Oct 17, 2018

I mean one single js file to reproduce the problem: https://ssr.vuejs.org

@TheAlexLichter
Copy link
Contributor Author

Whoops. There you go:

// Step 1: Create a Vue instance
const Vue = require("vue");
const app = new Vue({
  template: `
  <div v-make-red>
    <h1>This should have red style!</h1>
  </div>
  `,
  directives: {
    makeRed: {
      inserted(el) {
        console.log("client directive");
        el.style.backgroundColor = "blue";
      }
    }
  }
});

const makeRed = (node, dir) => {
  const style = node.data.style || (node.data.style = {});
  console.log("server directive");
  if (Array.isArray(style)) {
    style.push({ backgroundColor: "red" });
  } else {
    style.backgroundColor = "red";
  }
};

// Step 2: Create a renderer
const renderer = require("vue-server-renderer").createRenderer({
  directives: {
    makeRed
  }
});

// Step 3: Render the Vue instance to HTML
renderer.renderToString(app, (err, html) => {
  if (err) throw err;
  console.log(html);
  // <div data-server-rendered="true"><h1>This should have red style!</h1></div>
  // But should include red background-color style
});

@TheAlexLichter
Copy link
Contributor Author

Of course, simply changing the declaration to { 'make-red': makeRed } would make the example work, but there is an inconsistency between client-side directive registration (which works in both kebab-case and camelCase) and server-side directive registration (only kebab-case)

@posva posva added the bug label Oct 17, 2018
@posva posva changed the title vue-server-renderer: Allow camelCased SSR directives vue-server-renderer: camelCased local directives are not applied in SSR Oct 17, 2018
@posva
Copy link
Member

posva commented Oct 19, 2018

go ahead, nobody is working on this atm

ggtmtmgg added a commit to ggtmtmgg/vue that referenced this issue Dec 1, 2018
SSR directives can be only passed in with 'kebab-case' keys, but Client size rendering can be passed
in with 'camelCale' keys.

fix vuejs#8961
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

2 participants